Názory k článku PHP pro experty: databázové rozhraní

Nemela by to byt firma MySQL AB? :))
Ze by nekomu vadila formulace "firma MySQL AB k MySQL..." :)

Přijde mi jako téměř neodpustitelný hřích nezmínit zde PEAR a jeho FormBuilder.
Skript createTables umí generovat třídy DB_DataObject (objektové mapování relačních tabulek) na základě struktury databáze (při změně struktury můžete přegenerovat, aniž byste přišli o Vámi dodaný kód). Dále můžete dodefinovat přiřazení cizích klíčů (pokud to Váš DB stroj neumí) atd.
No a FormBuilder k výše uvedenému umí vytvářet instance HTML_Quickform a samozřejmě do toho můžete zasahovat na mnoho způsobů...

tohle reseni se mi taky velice osvedcilo (az na to automaticke generovani formularu, to mam trochu jinak, ale html_quicforms pouzivam). Jeste k tomu mam Smarty a programuje se v tom bozsky :) uz na tom bezi nekolik celkem velkych webu

A kde je to PHP?

nevím, tady http://www.php.net ?

To PHP je přece v smartbee ;-). Jen na těch stránkách jaxi nevidím, co to vlastne smartbee je a číst ty zdrojáky se mi moc nechce.

Data v DB by bylo nejspíš možné spravovat i z OpenOffice.org. Formuláře tam vytvářet lze, připojit se k DB přes ODBC také... a je to přeci jen přenositelnější řešení.

Open Office jsem zkoušel. Máte nepatrnou chybku, OO se nepřipojuje přes ODBC, ale přímo se konektí na MySQL, má to zabudováno.

Nicméně Open Office je nedostatečné řešení. Umí pracovat s těmi daty, udělat pár triků, ale funkčností se to Accessu vůbec nedorovná. Ne nadarmo se říká, že OO je na úrovni MS Office 97.

Nechci tu vypoutávat flamewar, OO je určitě dobrý produkt a mnoha lidem stačí, ale k funkčnosti MS Office XP to má bohužel daleko, alespoň vám to potvrdí každý, kdo navštívil školení pro pokročilejší uživatele

:-) Máte dojem, že prosazuji OO "za každou cenu"? Nebo že tvrdím, že je na danou činnost OO vhodnější než Access?

Pokud ano, je to špatný dojem. Cituji ze svého původního příspěvku: "... by nejspíš bylo možné použít...". Mám dojem, že z toho je jasně vidět ten entuziasmus, to zapálení pro OO, které mám. ;-)

Ale Vás může těšit vědomí, že jste připsal do diskuse nějaké moudro a že jste dal "tomu fanatikovi" co proto.

Ked uz je o tom rec uz nejaky asi 2 mesiac vyvijam framework pre formulare a tabulky, pretoze som ho uz pouzil asi na 3-4 projektoch myslim si, ze je uz celkom hotovy, ak ma niekto zaujem mozem na poziadanie poslat, na web ho zatial nejdem davat, dokial k nemu nespravim dobru dokumentaciu. Nuz ale dost slov, radsej napisem co obsahuje:
- tabulka a formular je reprezentovany formou objektu
- na generovanie vzhladu sa pouziva FastTemplate, a teda je mozne oddelit vzhlad od kodu.

- objekt tabulka
- automaticke generovanie strankovania
- automaticke generovanie zoradovania
- neviem ci vyhoda, ale strankovanie a zoradovanie je cez formular
- vykreslenie priamo, alebo vratenie vystupu ako retazec
- moznost reagovania na data pomocou funkcie
- viacriadkove data

- objekt formular
- automaticke generovany select, insert, update podla predaneho id a nastaveneho stlpca z tabulky
- funkcie na zachytenie on_data, on_check, on_store
- automaticke validovanie hodnot pri int, float, date, text na dlzku, format, atd
- osetrenie dat na magic_quotes

Pouzitie je uz potom len na par riadkov.
Tak ak to bude chciet niekto vyskusat a pomoct my vychytat chyby, mozno to nakoniec pomoze aj jemu:)

to vsetci php experti pouzivaju msaccess ?
no zbohom :)

skor by som sa radsej orientoval na tie fremeworky ako ukazovat, ze adminovat web sa da vlastne aj z prikazovej riadky ..

Nevim, nadepsat clanek PHP pro experty a pak zacit pohadkou pro deti... Jinak zajimave tema, jsem zvedav, co se z toho vyvrbi :)

Ja pridam odkaz na svuj framework:

http://dblib.sourceforge.net

To vypadá docela dost rozumně, tenhle framework si asi projdu :) Umí to i relace?

Co je to "umi to relace" - jestli to umi ciselniky? Samozrejme ano. Dokonce dvema zpusoby - byt jako COMBO nebo jako popup okno s moznosti hledani (DBLLCField a DBLJSLCField).

Rovnez to umi jednoduse udelat, aby text byl HTML odkazem na detail odkazovaneho zaznamu.

Jedina vetsi vec, co mne napada ze to neumi jsou templaty, ale to se da vice ci mene nahradit pomoci technik OOP (pretizeni metod na vypisovani toho ci onoho).

BTW, ted jsem udelal release nove verze, jsou v ni ruzne bugfixy a mala vylepseni, ktera se mi tu za par mesicu nahromadila :-)

Nemuzu soudit jak je to napsane uvnitr, ale ovladani je vice nez nepouzitelne, je problem se zorientovat co zrovna edituju atd, cybi mi tam a to hodne razeni.
Absence sablon tomu taky neprida a nepomuze ani oop.
sorry za kritiku ;]

Ovladani nepouzitelne: Hm, pouzivam to ja, pouziva to i dost uzivatelu a zadne podstatne negativni ohlasy jsem nezaznamenal. Rad ho upravim, ale budte konkretnejsi.

Co edituju: Obavam se, ze to je spis problem te demo aplikace, nez knihovny same ;-)

Razeni to ma ve formulari filtru, ktery je jen na jedne z ukazek, viz: http://cars.dblib.dateso.cz/admin/model/

S temi sablonami - ja jsem nikdy nepocitoval (v administracnich systemech) nejakou podstatnou potrebu menit vzhled... Priznam se, ze jsem pripadnou moznost nasazeni sablon na DBLIB detailneji nestudoval. Nicmene pravdepodobne by melo stacit vytvorit potomka tridy DBLView, ktery by vystupy misto primo v HTML delal v sablonach.

Kdyz uz jsme u toho, www.nalanda.cz je take delano pres DBLIBku i vcetne velke casti uzivatelskeho rozhrani ;-)

P.S.: Ja se kritiky nebojim ;-)

Je to samozrejme o pristupu, ale co se ovladani tyce napr pri editaci se stracim protoze nevidim co mam zvoleno, proto preferuji model, kde je videt i list a co je zvoleno.

Casto se mi stava, ze mam na strance nekolik objektu, ktere se navzajem ovlivnuji
strom->list->zalozky->formular atd.
mel bych zde vitku k tomu, ze nejsou zabaleny jednotlive promene daneho objektu napr pod jedno pole atd. (pouzivam jakoby stromovy model aplikace a nazvy polozek formulare, ci promene nastaveni se generuji page[items][tree][items][form][items][name_of_item], ale to je pouze vsuvka)

Ok omlouvam se za razeni, ale precejen bych ho cekal kliknutim na header sloupce ;]

K čemu to všechno je (mluvím o generátorech kódu)? Aby to odstínilo designera od znalosti SQL a potažmo i php? Já vím, že mi odpovíte, že to urychluje práci, ale mám z toho takový nepříliš dobrý pocit. Automatizace rutinních funkcí je jistě důležitá, ale zdá se, že to směřuje k tomu "one size fit all solution".

Osobně jsem pro staré dobré kódování ručně. PHP je nádherný jazyk a je škoda nevyužít všech jeho nuancí. Stejně tak SQL.

Ja jsem svoji DBLIB zacal psat na zaklade psani par webu, kdyz jsem zjistil, ze dobrou polovinu casu mi zabira programovani tech samych veci - nacist radek, pripadne seznam radku) z DB, zobrazit v tabulce oscapovane htmlspecialchars(), prijmout data z formular, zkontrolovat, oescapovat AddSlashes(), vlozit do DB. Ten kod byl prakticky porad to same.

Jak vidite z poctu ruznych frameworku, tak "one size fits all" rozhodne nehrozi :-)))

(A mimochodem, programovani s takovym frameworkem je podstatne bezpecnejsi, protoze framework se (typicky) postara o spravne escapovani vsech hodnot.)