Občas trochu nechápu logiku vývojářů PHP, ne že by to byl zcela špatný jazyk, leč někdy mi připadá navržen jako když „kočička s pejskem pekli dort“.
Jeden ze základních problémů vnímám v nejednotnosti API, několik funkcí ze stejné skupiny má několik způsobů uspořádání vstupních parametrů a někdy je nutná konzultace s dokumentací.
Co mě irituje poslední dny je předávání polí z HTML formuláře. Když přidám i pole pro soubory, bude nelogické uspořádání dimenzí pole markantní. (Upozorňuji, že stále píši v HTML4, jelikož jsem XHTML neuznal jako životaschopnou normu a současný vývoj mi dal víceméně za pravdu.)
Zdrojový kód formuláře:
<form action="" enctype="multipart/form-data" method="post">
<p><em>Pole1:</em> <input name="txt[1]" type="text" /></p>
<p><em>Pole2:</em> <input name="txt[engl]" type="text" /></p>
<p><em>Soubor1:</em> <input name="soub[1]" type="text" /></p>
<p><em>Soubor2:</em> <input name="soub[1]" type="text" /></p>
<input type="submit" value="Odes*at" />
</form>Pokud chci zpracovat data z textových polí $_POST, najdu je zcela logicky na pozicích jméno vstupu a klíč pole (nejen číselný, lze použít i text), neboli $_POST['txt'][1] a $_POST['txt']['engl']. Ale pokud chci ze superglobálního pole $_FILES zpracovat soubory stejným způsobem (tj. ověřit zda nenastala chyba, zkopírovat, …) narazíte na menší nelogičnost v uspořádání dimenzí.
Standardně bych očekával, že k jednotlivým údajům se dostanu sekvencí $_FILES[nazev][klic][udaj], kde nazev je moje pojmenování inputu z formuláře, klic je klíč pole; mnou zvolený index; a udaj je vlastnost, jíž potřebuji (z množiny name, tmp_name, size, error a type). Odpovídalo by to logice přístupu k nesouborovým hodnotám $_POSTu.
Avšak přístup k hodnotám je malinko přeházený, jako programátor dovedu pochopit rozhodnutí, jež k tomu vedlo. Správná sekvence jednotlivých indexů je $_FILES[nazev][udaj][klic], přičemž jednotlivé indexy jsou popsány v předchozím odstavci.
Zkušení programátoři pochopitelně znají, já už jsem se soubory v poli dlouho nepracoval, takže jsem na přeházenou indexaci zcela zapoměl.
Komentáře
8 komentářů: „PHP: Pole $_FILES je trochu naruby“
Ahoj
API v PHP představují obalené populární Unix knihovny – o nějaké koncepčnosti nebo konzistenci se vůbec nedá mluvit – teprve některé "moderní" knihovny jsou víc než wraper. Fakt nevím, jak to původně autoři mysleli – možná to brali tak, že bude výhodnější ty knihovny nijak zvlášť nepřepisovat – by nemuseli přepisovat původní dokumentaci.
@Pavel Stěhule: Jj, také jsem viděl. Smutná pravda, chtělo to zapnout hlavu, nejen mechanicky wrapovat. Už mizí alespoň „vtipnosti“ jako dvě funkce, jež dělají totéž, ale přidali je dva programátoři nezávisle na sobě, tak mají jen různá jména (kvůli kompatibilitě pro starší programy se jedna z nich stala symlinkem na druhou). Kdyby nebyl tak triviální deployment a nebylo PHP „všude“, tak se jím snad nezabývám, ale to je obchod.
Ahoj,
taky vnímám API v PHP jako děsně zmatené a na často používané věci mám své vlastní třídy (utility), které pak využívám napříč vlastními projekty. Jak si jednou člověk zvykne na logiku a uspořádání v Javě nebo aspoň Pythonu, tak se pak k PHP těžko vrací. Ale pro soukromé projekty je to prostě nejsnazší cesta, multihosting mám za 70Kč na měsíc a spokojeně na něm běží zhruba 10 nenáročných webů v PHP. Pro Javu bych asi nic obdobného nesehnal.
@tdvorak: Newrapuji, radsi se kouknu, byť to zdržuje. Jsem trochu konzerva a abych místo volání jedné funkce dělal mezikrok mi přijde zcestné, bohužel jsem se učil programovat na 8bitech a trend využití každého promile výkonu mi k srdci nikdy nepřirostl.
V PHP se dají napsat i dost velké projekty, kdyby (jako Python) dělal při prvním spuštění bytekód, byly by limity ještě výše. Jinak mě živí .NETění, webařinu dělám spíš ze zájmu (dokonce ani aktivně nehledám zákazníky, ale spolupracuji s designerem, který umí design, leč neumí programovat).
@Marek: tehdy to mohlo vypadat jako docela dobrý nápad – tím, že se nevymýšlelo API, bylo relativně rychle relativně dost knihoven. Dobu, kdy vznikalo PHPko si asi oba dva pamatujeme. Java byla asi první, která měla konzistentní a obsáhlou knihovnu. Všechny ostatní jazyky měly ještě knihovny, které více – méně vycházely z API operačního systému. Pro web tou dobou existovalo snad jen docela šílená ASPčka, vůči kterým byl bylo PHPko o dvě generace vpřed. Na Linuxu byl primární jazyk Perl, který má podobně nekonzistentní knihovny dodnes. Všechny jazyky před Javou jsou z dnešního pohledu neergonomické bazmeky – Javou – jejím API se udělal šílený skok dopředu – a novější jazyky už z toho těží. Bohužel PHP zatím nepřišlo s dobrým API a dnes už je asi docela pozdě – na webu se už asi nic zvláštního dít nebude – frčí mobily a tablety (kde PHPko nehraje žádnou roli) – a z výhledem cca 10 let bude PHP postupně nahrazeno JavaScriptem (tipnul bych si to, ale P.B. ví) a tudíž od PHPka nečekám zásadní zvraty, kterými by spíš naštvali svou komunitu.
@Pavel: Javascript, správněji ECMAScritp, má dobrou budoucnost, ještě nedávno to byl velmi podceňovaný jazyk, ale na straně kleinta. Webové aplikaci napsané v HTMLx s JS je potřeba servírovat data, a to je místo PHP, eventuálně ASP/JSP/…. Pamatuji si pokus o nasazení JavaScripu na straně serveru, byl to SSJS (Server Side JavaScript) od Netscape a dnes znám i Node.js, který jde podobným směrem, ale lépe, leč zda prosadí bych si absolutně netroufl odhadovat.
@Marek: Pán Bůh ví, jak to dopadne – s JavaScriptu (ECMAScriptu) mám pocit, že je to jazyk, kolem kterého je asi největší "humbuk", kolem kterého se něco děje – něco podobného s Ruby kolem roku 2005 – oproti Ruby je JavaScript podstatně víc rozkročený, a navíc na první pohled nevypadá tak excentricky jako Ruby 🙂
@Pavel: Alespoň nejsem jediný pro koho vypadalo Ruby maximálně excentricky :-D, ještě pár zavináčů a málem měli další ezoterický jazyk. Kamarád říkal že jeho vize ideálního jazyka je kříženec mezi Pythonem a Ruby. Ruby pro scriptování na počítači je fajn, ale pro psaní webu narazíš na jeden problém, sebelepší jazyk je na prd, když není hosting a psal by’s leda pro sebe na vývojový webserver, nebo měl pronajatý/hostovaný (virtuální) server, nikoliv klasický webhosting. AFAIK: Python a Perl jsou na tom s možnostmi deploymentu podobně jako Ruby, Java trochu lépe a jediné snadno dostupné hostingy najdeš pro .NET (na této technologii se mi ale moc vyvíjet nechce) a zase ty PHP.