[HTTP] Array posten vanuit form

[eghie]

Ik wil aan de slag met een javascript library die multiple fileupload mogelijk maakt, via graceful degradation, die standaard, wanneer aanwezig, gebruik moet gaan maken van de nieuwe HTML5 mogelijkheden, zoals de File API. Omdat dit een clientside javascript library wordt, wil ik een beetje de standaarden proberen te houden, zodat hij voor elke serverside taal ingezet kan worden, zonder dat je veel dingen hoeft te verbouwen.

Even een verzameling aan serverside talen, waar ik primair rekening wil houden:

• PHP
• JAVA
• ASP.NET
• Ruby
• Python
• Perl

Omdat ik de laatste aantal jaar voornamelijk met PHP bezig ben, weet ik niet goed wat de standaard nu is.

Ik wil via de multifile upload de files posten als vorm van array. Nu moet je die ook meerdere malen in de pagina kunnen gebruiken. Dus je krijgt soort van bestanden die in dezelfde group behoren. Omdat ik dus graceful degradation wil gebruiken, krijg je ook meerdere file upload boxen als er totaal geen ondersteuning is voor multi file upload. Dit is een voorbeeld:

code:

<input type="file" name="fileupload" />
<input type="file" name="fileupload" />
<input type="file" name="fileupload" />

Nu moet je bij php, als je arrays wil posten, [] of [index] achter de waarden zetten. Dit hoeft echter niet bij ASP.NET bijvoorbeeld.

Ik was pas bezig met een OAuth clientside library en kwam ik in de OAuth documentatie de volgende citaat tegen:

quote: http://oauth.net/core/1.0a/#anchor13

If two or more parameters share the same name, they are sorted by their value. For example:

code:

a=1, c=hi%20there, f=25, f=50, f=a, z=p, z=t

Hier zie je 2 waarden op dezelfde variable f. Deze moeten naar mijn inschatting als array behandeld worden. Dit pakt PHP eigenlijk niet op.

Ik heb even wat test code ervoor gebouwd:

PHP:

<form method="post">
    PHP array:
    <input type="text" name="phparray[]" value="a" /><br/>
    <input type="text" name="phparray[]" value="b" /><br/>
    <input type="text" name="phparray[]" value="c" /><br/>
    <p></p>
    
    HTTP array:
    <input type="text" name="httparray" value="1" /><br/>
    <input type="text" name="httparray" value="2" /><br/>
    <input type="text" name="httparray" value="3" /><br/>
    <p></p>
    
    <h3>File upload</h3>
    
    PHP array:
    <input type="file" name="phparrayfile[]" /><br/>
    <input type="file" name="phparrayfile[]" /><br/>
    <input type="file" name="phparrayfile[]" /><br/>
    <p></p>
    
    HTTP array:
    <input type="file" name="httparrayfile" /><br/>
    <input type="file" name="httparrayfile" /><br/>
    <input type="file" name="httparrayfile" /><br/>
    <p></p>

    <input type="submit" name="submit" value="Submit" />
<pre style="border: solid 1px black">
    Post:
    <?php var_dump($_POST); ?>
    
    File:
    <?php if (!empty($_FILE)) var_dump($_FILE); ?>
</pre>
</form>

Resultaat:

code:

array
  'phparray' => 
    array
      0 => string 'a' (length=1)
      1 => string 'b' (length=1)
      2 => string 'c' (length=1)
  'httparray' => string '3' (length=1)
  'phparrayfile' => 
    array
      0 => string '' (length=0)
      1 => string '' (length=0)
      2 => string '' (length=0)
  'httparrayfile' => string '' (length=0)
  'submit' => string 'Submit' (length=6)

Nu heb ik het idee dat PHP die arrays niet volgens de standaarden behandeld en de rest van de talen dat wel goed oppakt. Welke manier moet ik nu aanhouden om array's te posten, zodat het zoveel mogelijk serverside taal onafhankelijk wordt?

En moet ik nog rekening houden met files uploaden naar verschillende serverside talen?

[_eXistenZ_]

Het lijkt mij juist dat PHP dit perfect doet, je schrijft als je geen index opgeeft gewoon keihard de vorige (voor zover dit al mogelijk is natuurlijk, is het uberhaupt valid?) Gewoon een array opgeven met haakjes en een key er in.

[ Voor 13% gewijzigd door _eXistenZ_ op 11-04-2010 20:39 ]

[eghie]

_eXistenZ_ schreef op zondag 11 april 2010 @ 20:38:
Het lijkt mij juist dat PHP dit perfect doet, je schrijft als je geen index opgeeft gewoon keihard de vorige (voor zover dit al mogelijk is natuurlijk, is het uberhaupt valid?) Gewoon een array opgeven met haakjes en een key er in.

Dit pakt PHP:

poststring: blah[]=1&blah[]=2
php: $_POST['blah'] = array(1,2);

Dit pakt PHP niet:

poststring: blah=1&blah=2
wordt nu in php: $_POST['blah'] = 2;
php zou naar mijn idee dit moeten doen: $_POST['blah'] = array(1,2);

terwijl ASP.NET bijvoorbeeld dat laatste wel pakt, maar die eerdere niet. Volgens de regels van HTML mag je name="" meerdere keren gebruiken en betekend dezelfde naam hoort bij dezelfde groep. Bijvoorbeeld bij meerdere checkboxes of bij meerdere radiobuttons.

Dus ik vraag me haf hoe dit in een serverside taal onafhankelijke manier op te lossen.

[ Voor 3% gewijzigd door eghie op 11-04-2010 23:19 ]

[Cartman!]

Dat je het name attribuut vaker mag gebruiken omschrijft natuurlijk niet hoe dit door een serverside-taal afgevangen dient te worden. Of er dus sprake is van een standaard waar een taal zich niet aan zou houden is twijfel ik sterk aan. De vergelijking met OAuth is erg scheef omdat dit een losstaande techniek is.

[eghie]

Cartman! schreef op zondag 11 april 2010 @ 23:25:
Dat je het name attribuut vaker mag gebruiken omschrijft natuurlijk niet hoe dit door een serverside-taal afgevangen dient te worden. Of er dus sprake is van een standaard waar een taal zich niet aan zou houden is twijfel ik sterk aan. De vergelijking met OAuth is erg scheef omdat dit een losstaande techniek is.

Ik trek niet zozeer de vergelijking met OAuth. Dat citaat viel me op in de documentatie, waardoor ik met deze vraag eigenlijk kom.

Ik weet niet zeker of het een standaard is en of PHP perse fout omgaat met een standaard, maar dat is zowel zoals het lijkt. In RFC3986 kan ik er niks over vinden. Maar geen idee of iets een standaard is waar het overal mee werkt. Daarnaast wil ik hiermee ook kijken hoe PHP ermee omgaat in vergelijking met de rest van de talen, zodat ik weet hoe ik ermee om moet gaan.

[Wolfboy]

PHP is niet de enige taal waarbij je met [] een array kan specificeren, bij Ruby on Rails kan je ook dingen als foo[bar] doen iig. Al hebben de andere talen daar niet allemaal echt een standaard voor. Je zou PHP en ASP.Net dan ook moeten vergelijken met web frameworks zoals Ruby on Rails, Django of Spring.

Echt consistent is het helaas niet kwa volgorde, ik denk dat de enige echt cross-framework optie is... lever wat code mee. Bij Django is het in ieder geval zo dat de volgorde waarin je het submit ook de volgorde is waarmee je het uitleest. Net als bij PHP dus.

Er is iig geen enkele mogelijkheid die overal direct werkt, het zal sowieso geconfigureerd moeten worden

[Janoz]

Er is helemaal geen definitie over hoe om te gaan met hetgeen je binnen krijgt. Het enige wat gedefinieerd is, is dat alle form velden in het formulier als name-value pairs doorgegeven worden. Als er meerdere dezelfde names zijn dan worden er meerdere name-value met dezelfde name opgestuurd. Wat er serverside mee gebeurt is geheel de keuze van de ontwerpers van php, asp , enz.

Voor beide keuzes is wat te zeggen. De keuze van PHP heeft bijvoorbeeld als voordeel dat het type van een get of post variabele meer vast staat. (Achter de url iets als p=3 zetten terwijl je even niet doorhad dat de p al werd gebruikt zorgt er niet voor dat je applicatie raar gaat doen omdat het type van p ineens een array geworden is).

Om eerlijk te zijn vind ik in deze de keuze die php gemaakt heeft logischer (dat ik dat ooit nog een keer op een publieke plek neer zou zetten ) dan die van ASP.NET.


Maar om op je originele probleem terug te komen. Dergelijke verschillen zul je altijd tegen komen, vooral omdat 'array' niet iets is wat gedefinieerd is in de http specs. Je kunt je waarschijnlijk beter richten op het daadwerkelijk in kaart brengen van wat de verschillende serverside oplossingen verwachten en er vervolgens voor zorgen dat je component zo geconfigureerd kan worden dat deze met allen overweg kan.

[eghie]

Hmm, dan laat ik de ontwikkelaar die het implementeert het wel regelen. Dan moet de ontwikkelaar bij de name attribuut maar [] erin zetten als name, zodat PHP en Ruby enzo dat oppakken en als de taal dat niet pakt, die blokhaken maar weghalen.

Iets als:

php:

JavaScript:

var component = new MultiFileUploader({ name: 'uploadfiles[]' });

en ASP.NET:

JavaScript:

var component = new MultiFileUploader({ name: 'uploadfiles' });

En dat maar als opmerking in de documentatie erbij zetten.

[mithras]

Of je krijgt een optie om de blokhaken te zetten/verwijderen. Een framework/library is toch juist voor dit soort dingen op te pakken?

By default zou ik voor de ondersteuning kiezen van het meest gebruikte platform. Als je verwacht dat ASP.NET veel als backend gebruikt zal worden, moet je een andere keuze maken dan het moment dat je weet dat php 99% gebruikt zal worden

[ Voor 10% gewijzigd door mithras op 12-04-2010 10:27 ]

[eghie]

mithras schreef op maandag 12 april 2010 @ 10:27:
Of je krijgt een optie om de blokhaken te zetten/verwijderen. Een framework/library is toch juist voor dit soort dingen op te pakken?

By default zou ik voor de ondersteuning kiezen van het meest gebruikte platform. Als je verwacht dat ASP.NET veel als backend gebruikt zal worden, moet je een andere keuze maken dan het moment dat je weet dat php 99% gebruikt zal worden

Misschien is dat wel handiger ja, om een optie te hebben waarbij je aangeeft op je blokhaken wilt of niet. Scheelt wel weer wat rekenkracht met het verwerken van de parameters. Al hoewel het niet veel scheelt. Maar maakt de afhandeling in de code wel wat simpeler.

Het meest gebruikte platform schat ik Ruby en PHP. Dus misschien wel handig om daar rekening mee te houden. Ik zou misschien een autodetect optie aan kunnen toevoegen. Ik zou bij ASP.NET bijvoorbeeld kunnen controleren of er een VIEWSTATE aanwezig is. Maar dat wordt wel wat ingewikkelder en fout gevoeliger. Dus ik denk dat ik dat maar niet doe.

Maar van het meest gebruikte serverside taal uitgaan lijkt me wel handig ja. Ik ben altijd wel voorstander van code wat eigenlijk zo goed als meteen werkt, zonder al te veel configureren.

[Wolfboy]

Janoz schreef op maandag 12 april 2010 @ 09:41:
Voor beide keuzes is wat te zeggen. De keuze van PHP heeft bijvoorbeeld als voordeel dat het type van een get of post variabele meer vast staat. (Achter de url iets als p=3 zetten terwijl je even niet doorhad dat de p al werd gebruikt zorgt er niet voor dat je applicatie raar gaat doen omdat het type van p ineens een array geworden is).

Om eerlijk te zijn vind ik in deze de keuze die php gemaakt heeft logischer (dat ik dat ooit nog een keer op een publieke plek neer zou zetten ) dan die van ASP.NET.

Dan vind ik de Django methode nog beter eigenlijk
Daar heb je request.GET.get('p') om de laatste te krijgen of request.GET.getlist('p') om een lijst te krijgen (die dus meerdere items zou kunnen bevatten). Dat je met PHP het spul helemaal niet kan ophalen is imho wel suboptimaal

[crisp]

Wolfboy schreef op maandag 12 april 2010 @ 12:50:
[...]
Dan vind ik de Django methode nog beter eigenlijk
Daar heb je request.GET.get('p') om de laatste te krijgen of request.GET.getlist('p') om een lijst te krijgen (die dus meerdere items zou kunnen bevatten). Dat je met PHP het spul helemaal niet kan ophalen is imho wel suboptimaal

Je kan in PHP wel de 'raw' POST-data ophalen mbv php://input. Het grootste probleem is dan echter nog file-uploads; daar is geen manier om aan de 'raw' data te komen:

php://input is not available with enctype="multipart/form-data"

[ Voor 5% gewijzigd door crisp op 12-04-2010 12:57 ]

[Wolfboy]

Die feature kende ik nog niet, leuk dat ze inmiddels toch een mogelijkheid hebben om de data op te vangen Het gemis van multipart zal meestal toch geen heel groot probleem zijn.

[Tjeemp]

Kun je dmv een javascriptje niet een hidden input laten vullen met de waardes die in de file upload inputs worden geplaatst. Dan kun je ze bijvoorbeeld scheiden door een ; en gewoon in een string stoppen en dan de server-side taal zelf de string uit laten pakken tot een array.

[ Voor 3% gewijzigd door Tjeemp op 12-04-2010 14:55 ]

[Janoz]

De oplossingen van Crisp en Tjeemp vereisen nogal veel handelingen serverside. Zeker wanneer je een framework aanbied wil je juist dat de afhandeling serverside zo transparant en zo dicht mogelijk bij de standaard voor die serverside oplossing zit.

@Wolfboy: Optie 3 (van Django) is inderdaad mooier dan optie 1 en 2 .