PHP a formuláře

14.8.2006 21:00 | Linux | poslední úprava: 7.6.2019 18:27

.        

Komentáře

[d.f.h]

Já si na to udělal takový ... udělátko . Formulář se nadefinuje jednoduchým XML, který obsahuje pro každý vstupní pole jeden element s atributama povinný / nepovinný, defaultní hodnota, typ validace, typ pole (text, textarea, radio, checkbox...) atd.. Jednodouchou XSL transformací pak z tohohle definičního souboru vyrábím HTML formulář, kterej vkládám do jakýkoli HTML stránky pomocí AJAXu. Odeslání probíhá taky přes AJAX, tj. stránka se nereloaduje, pouze se v případě nesprávně vyplněnejch vstupních polí dá tato skutečnost vizuálně najevo. Pokud je všechno v pořádku, formulář zmizí a místo něj se vypíše libovolná hláška, nadefinovaná taky v onom definičním XML.

Data ukládám zatím zase jenom do XML, ale protože je PHP backend objektovej, není problém rozšířit metodu pro ukládání o použití databáze místo filesystému a pak v konfiguráku změnit jeden řádek.

Zatím mi to takhle vyhovuje, protože celá tahle věc vlastně nemá žádný administrační rozhraní - jenom edituju a čtu XML soubory, což je opravdu rychlý.

[rnj3e]

To zní zajímavě; jen skoro neovládám XML (XSL) a AJAXu se bojím (nějak v něj prostě nedůvěřuji); Tak mě právě napadlo udělat něco podobného - ale třebas z tabulek v databázi (protože s mými znalostmi si napíšu lépe skript pro parsování)- je to jen nápad

[d.f.h]

Jasně, je přece fuk, jak to kdo dělá, každýmu vyhovuje něco jinýho.

[Luk]

AJAX je sice hezká věc, ale obavy jsou skutečně na místě. Stačí mít starší (nebo třeba textový) prohlížeč nebo si vypnout Javascript a je po funkčnosti.

Podobné případy řeším většinou nepříliš elegantně, tedy v podstatě "hrubou silou", což znamená napsat dost kódu. Ale jestli mě paměť neklame, tak se tu někdo před časem chlubil (v blogu nebo v diskusi) nějakým vlastním frameworkem, který zpracování a kontrolu dat z formulářů řeší. Třeba by to šlo nějak vyhledat.

[d.f.h]

Jasně, souhlasím. Používám AJAX jenom tam, kde se opravdu nepředpokládá byť jen existence něčeho, jako je textovej prohlížeč .

[Jiří (BoodOk) Kadeřávek]

Neni prece problem cely tento postup, tedy XML sablonu zpracovanou pres XSL transformaci zapracovat bez AJAXu. Taktez neni problem do XML sablony pridat elementu vlastnost mask, do ktere zapisu regularni vyraz, kterym musi vlozena hodnota projit. PHP skript XML natahne, provede transformaci do formulare a pri prijeti hodnot je porovna s prislusnymi maskami (regexpy). Neni to nic sloziteho, jen to chce znat XML, XSLT, pripadne praci s DOMem. Potom uz je vytvoreni a odladeni takoveho systemu prace maximalne na 2-3 hodiny.

[d.f.h]

Asi tak.

[Honza Král]

vzdycky me fascinuje kam az je schopen zajit clovek jen proto aby se nemusel ucet/nasazovat jiny jazyk.

Prijde mi, ze normalni by bylo, aby neco podobneho, nebo alespon zakladni prace s formularema, umelo PHP nativne, kdyz uz si hraje na to, ze je to vhodny jazyk pro tvorbu i rozsahlych webu.

Ja jsem treba tenhle problem vyresil nepouzivanim PHP, pouzivam misto toho Django., vytvorit formular je otazka chvilky, admin rozhrani mam zadarmo, stejne jako overovani prihlaseni, validaci, RSS apod. Jestli nekomu nevyhovuje python, je tu jeste ruby on rails, grails a dalsi...

muzete mi nekdo rict duvody proc pouzivat PHP, krome obvykleho - je to na vsech hostinzich apod. Prijde mi, ze PHP se pouziva proste ze setrvacnosti, jako windows.

[d.f.h]

Někdy prostě není možnost používat nějakej framework, resp. takovej, kterej by se člověku osobně líbil. A bohužel je to dost často.

[Jiří (BoodOk) Kadeřávek]

Zkusenosti a znalosti ziskane pri vytvareni vlastniho frameworku jsou vetsinou ty nejhodnotnejsi. Takze zatimco ty se budes ucit Django, tak on se nauci praci s XML, XSLT a DOMem a vytvori si vlastni framework. Na teto volbe neni nic zavrzenihodneho. A tato volba take dle meho odpovida na otazku, proc je PHP tak pouzivane. Odpoved: flexibilita.

[Honza Král]

ehm, takze PHP je flexibilnejsi nez python, perl nebo ruby? Imho neni

proti tvemu argumentu nemuzu nic namitat, je urcite dobre si nejaky framework napsat, jestli se skutecne chci necemu takovemu venovat do hloubky, ale to jen presouva mou puvodni otazku o rovinu jinam: Proc psat ten framework v PHP?

Navic puvodni otazka v blogu mi spis prisla stylu co bych mohl pouzit, aby to fungovalo, nikoliv abych se neco naucil. Presto ze si o sobe myslim ze nejsem uplne spatny programator (a o d.f.h. to i vim ;) ), tak budu nadale prosazovat, ze jestlize chci neco pouzit aby to fungovalo (ne, abych se neco naucil), je lepsi sahnout po vyspelem reseni stylu django/RoR/grails/JSF/cokoliv nez si neco psat. Je pomerne velka sance ze desitky/stovky lidi pouzivajici/vyvijejici tyhle frameworky odvedou lepsi praci nez ja sam.

[Jiří (BoodOk) Kadeřávek]

... je lepsi sahnout po vyspelem reseni stylu django/RoR/grails/JSF/cokoliv nez si neco psat.

Nastesti si to nemysleli tvurci techto frameworku, jinak by tyto nikdy nevznikly.

[Honza Král]

Situace v dobe vzniku django/RoR byla jina (grails a JSF je jen odpoved na tyto z rad javistu ;) )

Autori techto frameworku (alespon RoR a Django) vytvorili tyto, protoze nepovazovali PHP za dobrou alternativu, oba projekty vznikly pred X lety (minimalne 2-3), tedy v dobe kdy nic podobneho k dispozici nebylo. Skutecnost, ze si k implementaci nevybrali PHP a ze pro PHP neexistuje nic na podobne urovni necemu nasvedcuje.

Ja bych se ale rad vratil k te puvodni otazce proc PHP? poskytl jsem nekolik argumentu proti a ptal se po argumentech pro, zadne jsem nedostal -- vsichni se upenlive drzi PHP a jeste jsem neslysel duvod proc, tedy krome sekundarnich duvodu (hosting, setrvacnost, podnikova politika a spol.).

[Arnošt Málek]

Pred 6 lety jsme zacali psat IS, ktery mel pouzivat "tenkeho" klienta - prohlizec. V te dobe padla volba na PHP. Dnes je v PHP napsano spousta kodu a zacit psat v necem jinem je v podstate nemozne - musime porad rozsirovat funkcnost a ne prepisovat "jadro" - tam jsem rad ze funguje jak ma. Mozna k prepsani do jineho jazyka nekdy dojde, ale prozatim nevidim jediny duvod pro zmenu.

[Jiří (BoodOk) Kadeřávek]

Ja mam napsany vlastni MVC/AJAX framework v PHP a jsem _naprosto_ spokojeny. Proc bych menil? Na vasi otazku proc PHP? Protoze bylo prvni alternativou ASP na linuxu (nepocitam perl, ktery proste spousta lidi nemusi). A proc stale PHP? Protoze neudelalo zadnou _zasadni_ chybu, i kdyz tech mene zasadnich je jako maku a protoze ma skvelou podporu. Dnes se jedna o takove C pro web. Mate tam vse a nic. Dovoli vam vse a je jen na vas, jak se poperete prave se skutecnosti, ze dovoli vse. Co se tyce Python nebo Ruby. Python i Ruby nepouzivaji C syntaxi. To je treba problem pro mne, protoze kdyz kombinuje vice jazyku, mam problem prechazet mezi syntaxemi. U Pythonu mi navic vadi odsazovani, trochu jsem v nem delal a proste se mi nelibi, ze nemam tu volnost jako u C zapisu. A prestoze provozuji vlastni servery a mohl bych si vybrat jakoukoliv kombinaci Apache/jazyk, zustavam u PHP. Ani Java mne neoslovila, zejmena pak "manual" k J2EE. Ja chci jazyk, zbytek (frameworky, kontejnery, aplikacni servery) ne. Chci jen a pouze jazyk se kterym, pokud to je nutne, si ten zbytek vytvarim. Odmenou mi potom je temer totalni kontrola nad produktem.

[mrzout]

Protoze je mi syntaxe Ruby i Pythonu neprijemna?

Kazdymu vyhovuje neco jineho.

p.s. Formulare delam pres tridu z PEARu

[mrzout]

Jeste jsem chtel poslat tohle: http://www.symfony-project.com/tutorial/my_first_project.html

Princip je podobnej jako u djanga, tedy popsani vztahu v databazi atoho, co s nima hodlam delat.

Strasnej mohoch IMHO. A to odsazovani na presny mezery jak v Pythonu, fuj :)) Nicmene schopnosti vypadaji zajimave, musim to priznat. Zatim jdu ale cestou vlastnich trid, ktere se postupne uci vic a vic veci (a vic a vic molochovatej :))

[rnj3e]

A která třída to je? nedávno jsem se na Pear díval, ale nějak jsem tam nic nenašel

[mrzout]

http://pear.php.net/manual/en/package.html.html-form.examples.php

Ve skutecnosti pouzivam jejiho potomka, kde mam upravene nektere drobnosti. A na administraci mam vlastni tridy, ze kterych je teprve generovani formulare volano.

Na listovani mam take hotovou tridu. Po inicializaci tam pridavam sloupecky a muzu na ne navazat jejich vlastni Viewery (tridy, ktere jsou pri pruchodu listem zavolany a vraci obsah bunky).

Vzniklo to ale postupnym nabalovanim, uz to bude potreba poradne procistit. Nicmene pouzivam se to pomerne snadno, coz je v mem pripade brzda pokroku :)

Jsem zvedav, jestli vypadne neco rozumneho ze Zend Frameworku. Formulare tam zatim jeste nemaj a co je hotovo, je reseno pro mne casto dost neprijemne. Hlavne doufam, ze pujde rozumne pouzivat jen nektere komponenty, treba PDF nebo Lucene.

[Ritchie]

AJAX – přístupný web vám asi příliš neříká, že?

[Michal Vyskočil]

Ne všechny webové aplikace musí být na Internetu

[d.f.h]

Říká. Proč?

[Jiří (BoodOk) Kadeřávek]

Klid, to jsou nazory Tech Co Opakuji Dokola Omilana Fakta bez hlubsiho pochopeni podstaty problematiky.

[Ritchie]

Co tím chtěl básník prosím říci?

[Jiří (BoodOk) Kadeřávek]

Klise, rika ti to neco? To je totiz presne to, co si nam sdelil. Nic nez klise. Ajax totiz s pristupnosti nema nic spolecneho. Mozna tak konkretni implementace techto technologii, ale rozhodne ne technologie samotne. Takze, zkus nam sve klise rozvest a my muzeme protiargumentovat.

[Ritchie]

Rozhodně jsem nemyslel, že by AJAX implikoval nepřístupný web. Pokud to tak vyznělo, tak se omlouvám. Reagoval jsem na to, že autor odesílá formulář na jakékoliv HTML stránce jen pomocí AJAXu, což proti přístupnosti webu rozhodně je.

[Ritchie]

kterej vkládám do jakýkoli HTML stránky pomocí AJAXu

Nemyslím si, protože jinak byste tohle nemohl napsat.

[d.f.h]

Ale to se ví, že mohl. O žádným požadavku na přístupnost nebylo v původním příspěvku ani slovo a já opravdu nemám potřebu ohánět se něčím, co mi v daným případě svazuje ruce (nebudu zacházet do detailů, protože jsou naprosto mimo kontext). Žádnej z webů, se kterejma jsem měl zatím co do činění, naštěstí neměl cílovku v uživatelích lynxu apod. nebo ve skupině jedinců, která považuje za nutnost mít z nějakýho vyššího principu vypnutej javascript.

Chápu, že takový skupiny existujou a dokonce chápu i to, že některý prostě ani jinak nemůžou (třeba slepec, používající čtečku textu), ale to nic nemění na tom faktu, že pokud se kvůli některýmu z uvedenejch faktů k formuláři (nebo čemukoli), servírovanýmu AJAXem někdo z nich nedostane, nepřinese to žádnou velkou škodu ani jemu, ani provozovateli webu. To je prostě fakt.

Autor příspěvku se ptal, jak to s formulářema děláme my. Já to dělám takhle a tím to pro mě hasne, nikomu svoje (přiznávám, že nouzový) řešení nevnucuju. Na oplátku požaduju, aby mi zase nikdo nevnucoval ani nepodsouval nic jinýho.

[Michal Vyskočil]

Jenom bych dodal, že v MSIE se XMLHttpRequest hackuje přes ActiveX, stejně jako emulace metody responseXML, takže v něm nesmí být v rámci nějaké bezpečnostní politiky zakázán, ale to pravděpodobně víš

[Jiří (BoodOk) Kadeřávek]

V ramci bezpecnostni politiky je lepe zakazat cely MSIE K cemuz vyse uvedene docela prispiva.

[d.f.h]

Vím, ale naštěstí to jde to i trochu jinak.

[Jiří (BoodOk) Kadeřávek]

Pres iframe?

[d.f.h]

Třeba i tak. Fantazii se přece meze nekladou

[Ritchie]

Nechci vám nic vnucovat či podsouvat, pouze upozorňuji ostatní, že vaše řešení nebude ve většině případů vhodné, protože snižuje přístupnost webu.

Mimochodem, při čtení vašeho příspěvku se mi jen tak mimoděk vybavilo internetové bankovnictví Komerční banky.

[Zdenek.Z]

Ony neexistují aplikace, které jsou určeny třeba pro jednoho člověka nebo velice omezenou skupinu? Občas snad člověk ví, pro koho přesně to dělá.

[#Tom]

Pročpak? Prohližeče nepodporující Javascript jsou pro většinu uživatelů naprosto nepoužitelné. Když jsem si hrál s (e)Linksem, tak jsem nenarazil ani na jednu jedinou stránku, která by se mi v tom prohlížela dobře. Do toho spadá mj. návod pro Linux From Scratch, root.cz, abclinuxu.cz, informační systém Masarykovy univerzity a další.

[Ritchie]

Na zpracování formulářů jsem si napsal třídu, která běžnou práci s formulářem dělá za mě.

[peter_h]

Tak, tak, človek totiž po čase zistí, že píše dookola stále to isté. Ja to validujem napr. oproti regexpu. Potom to posielam do šablóny, keď sú hodnoty formulára validné, tak mam na to interface FormAction, ktorý ma jedinú metódu Action a tej sa predá form, Action môže tiež ešte rozhodnúť o validnosti (tušim je to aj nejaký design pattern, mne sa to zdalo takto lepšie, dal by sa samozrejme zakaždým dediť nový form).

[Josef Kufner]

Jojo, taky jsem to vyřešil v jedné větší aplikaci takle. Mám třídu, které se párkrát zavolá několik metod, tím se tam nasypou widgety (inputy) a pak se zkontroluje jestli je formular vyplnen (dalsi metoda). Pokud je, zpracuje se, pokud není vykreslí se. Tím se kompletní obsluha formulářů smrskla na 3 odstavce kódu: inicializace + 2 větve jednoho if, kde jedna větev je trochu delší (ale ne kvůli formůláři) a druhá má 1 řádek. Kompletní ukázka pro 3 inputy:

require_once "lib/page.inc.php";
require_once "lib/auth.inc.php";
require_once "lib/editor.inc.php";

$auth = new Auth();
$lvl = $auth->check_login();
$page = new Page("Pokus", $auth->get_username(), $lvl);
$page->generate_header();

$ed = new Editor($_POST, array(), $auth->get_userid(), 12345);
$ed->add_text_entry('item1', 'Polozka 1', true);
$ed->add_text_entry('item2', 'Polozka 2', true);
$ed->add_text_entry('item3', 'Polozka 3', true);

if ($ed->is_completed()) {
	// zpracovani dat
} else {
	$ed->render_form();
}

$page->generate_footer();

Je to opravdu celé. Včetně kreslení stránky okolo. To co se skrývá v editor.inc.php je už trošku delší. Brzy tohle i zbytek aplikace zveřejním, jen na to zrovna nemám čas.