Vytvoření administračního rozhraní v PHP
Školení, která pořádám
Finc se v článku PHP vs JSP ptá, za jak dlouho bychom byli schopni v PHP udělat to, co Roman Štrobl v NetBeans. Má se jednat o ukázku jakési Persistence, já v tom však spatřuji způsob vygenerování jednoduchého administračního rozhraní z databáze. Jak se můžete přesvědčit z následující prezentace, trvá to v PHP přesně 6 minut a 9 sekund včetně prodlev způsobených komentářem. Než se na ni podíváte, prohlédněte si prosím původní ukázku, kterou můj příklad kopíruje.
Pokud tyto dvě prezentace nezaujatě srovnám, vidím tyto rozdíly:
- V PHP stačí styl přidat na jedno místo, nemusí se ručně kopírovat do všech vytvořených souborů.
- Popisky sloupců se udržují na jednom místě. Pokud dojde ke změně, nemusí se měnit dvakrát.
- Jaký sloupec z číselníku se bude používat, se určuje centrálně, není potřeba to ručně měnit všude, kde je použit.
- Při vkládání záznamu není třeba zadávat ID.
Ukázka byla převzata pokud možno 1:1 (kromě předvedení třídění, což jsem si nemohl odpustit), příklad tedy nebyl ušit na míru a aplikace nebyla pro potřeby tohoto příkladu jakkoliv uzpůsobena. Kromě předvedených vlastností jich samozřejmě existuje desítky dalších.
Použitý nástroj se jmenuje Adminer Pro.
Diskuse
Otazkou je co je obsahem toho kompilatoru :) A jak dlouho trval jeho vyvoj. Je nekde dostupny? (spise by me zajimal pro studijni ucely nez k praktickemu vyuziti :) )
Jakub Vrána :
Vývoj začal na začátku roku 2003 a od té doby stále probíhá. Hlavní jádro jsem napsal asi za měsíc, od té doby průběžně přidávám funkčnost, kterou potřebuji. To je ale obvykle přímočaré, polovinu času zabere popis funkce v dokumentaci...
Dostupné to zatím nikde není. V podstatě od začátku vývoje (kdy jsem pochopil, jak silný ten nástroj je) přemýšlím, co s tím. Většinu věcí dávám k dispozici pod otevřenými a velice benevolentními licencemi (kód na tomto blogu nevyjímaje), ale u tohoto nástroje se mi moc nechce - představa, že to použije firma, která za vytvoření administračního rozhraní klientovi naúčtuje 50.000 Kč a přitom tím stráví 10 minut času a já z toho nebudu mít nic, se mi moc nelíbí.
Zvažoval jsem, že bych z toho udělal službu - nahrajete SQL, vrátí se vám ZIP s administračním rozhraním, platba za řádek SQL. Nebo jako normální produkt určený pro webová studia za ne zcela malý peníz. Pokud by mi někdo chtěl pomoci s marketingem a prodejem, uvítal bych to.
Vesta:
Chápu, že se ti to nikomu nechce dávat zadarmo, když jsi na tom strávil tolik času. Vypadá to super. Už dlouho hledám podobný nástroj (klidně i za peníze), ale prozatím smůla. Takže jsem zvědavý na podmínky použití / prodeje.
honza:
to snad nehrozí. Pokud někdo chce jednoduchou editaci, tak přece nezaplatí 50 000 ne? Krom toho, ten generator je asi mocný, ale všechno nepokrývá jinak už by php programátoři byli bez práce a Jakub Vrána by se objevoval každoročně v časopisu Forbes :))
Ale i tak je výhoda na straně Netbeans. Ty stačí stáhnout a používat. A když už někdo udělá takové terno, že dělá aplikace ja na běžícím pásu, tak za ušetřené peníze za programátora může hostovat tyto java aplikace :)
Jakub Vrána :
Generátor pokrývá kompletní vytvoření administračního rozhraní. Spousta práce zbývá ještě na vytvoření prezentace.
Výhoda NetBeans spočívá především ve firmě Sun, které se vyplatí vývoj produktu sponzorovat. Dokud za NetBeans Sun nestál, byl to komerční produkt. Za mnou žádná velká firma nestojí a já se zdráhám produkt sponzorovat osobně.
dgx:
Hezké :-)))
To se cení, místo slov připravit srozumitelné demo.
Lukáš:
Tak nevím, jestli je problém u mě, ale při prohlížení druhého videa mi Firefox sežral takřka 1 GB paměti…
krteQ:
Me tez :) musel jsem do IE
Jakub Vrána :
Program CamStudio, který jsem pro vytvoření dema použil, se o této nenasytnosti zmiňuje. Existuje tam i volba, která ji potlačí (Manage Flash player internal memory), bohužel mi při ní generátor SWF padal.
Mě Firefox 2 pod Windows XP taky zabírá paměť tempem asi 3 MB / s, ale po nějaké době se uklidní, část paměti vrátí a pak už se drží v rozumné míře.
Pokud by o to někdo měl zájem, mohl bych vystavit i originální AVI, ale je třikrát větší a navíc potřebuje speciální kodek.
Ladislav Láska:
No mě to dělá spíš flash player. Vsadil bych se, že bude někde bug ve správě paměti (nejspíše cache toho scriptu - žeby nechával vybalené framy v paměti?). 1GB RAM byl v pr., za chvíli swap a než jsem dokoukal demo, tak OOM killer.
Mirek:
Tak předně bych rád poznamenal že ten pán co namluvil tu Javovskou demonstraci by neměl mluvit anglicky, pokud to neumí.
Jinak gratuluji k velice pěknému generátoru rozhraní ;)
Lukáš: ano, zdá se že ten flash tam má nějakej memory leak :(
Pavel:
Jizlivost neni na miste. Jde o informacni hodnotu. Rozumet je mu dobre. Vy jiste umite lip, ale jeste jsem od Vas zadne video (natoz hodnotne) nevidel.
RD:
i mě by zajímalo jak se admin vytvořen, podělíte se s námi o nějaké informace? :)
LLook:
Tak předně bych rád poznamenal, že i přes silný český přízvuk se té angličtině dá v pohodě porozumět a to je rozhodující. Nebuďme tak prudérní.
Ještě bych upozornil na jeden detail, který z té Java demošky není zřejmý. Totiž že struktura komponent na stránce a jejich stavy se mezi požadavky ukládají v session. Proto je možné, že jednou URL http://localhost:8080/PersistenceDemo/faces/cd/List.jsp ukazuje seznam a za chvíli ta samá URL nabízí úpravu jednoho prvku. Že jednotlivé části admina nemají svá vlastní URL může občas vadit. A pokud s aplikací pracujete zároveň ve více tabech prohlížeče, může za určitých okolností být problematický takzvaný krok Restore View.
dgx:
> Že jednotlivé části admina nemají svá vlastní URL může občas vadit.
No občas... Nedovedu si představit jediný případ, kdy by to nevadilo, naopak o nevýhodách by se dala napsat kniha.
Jinak ta českoangličtina je parádní, rozumím jí mnohem líp než angličtině original ;)
LLook:
Jj, spousta z nás se přesně tuhle variantu angličtiny učila na škole. :-)
Jinak se dá říct, že pokud jsi zděšen z ASP.NET, budeš zděšen i z JSF. Rozdíl je v tom, že JSF ten "viewstate" ve výchozím nastavení cpe do session proměnné a to je podle mě ještě horší...
finc:
Je dobré říct, ze samotná JSP stránka se stává servletem, stejně jako JSF Backing Beana.
Jinak co se týče toho URL, tak v tom nevidím žádný problém, možná by stálo za to se podívat, jakým způsobem se vlastně tvoří navigace (Navigation Rules) v JSF.
Ondra:
A co je špatného na ukládání něčeho do session proměnné?
Jakub Vrána :
Především to, že si nemůžeš otevřít dvě okna a v každém třeba pracovat s jiným záznamem. Další věc je, že stránka nemá pevné URL, takže se na ni nemůžeš odkazovat (třeba uložit do bookmarků, poslat e-mailem při změně záznamu, ...)
PIF:
náhodou, škoda, že i Jakub nám neukázal angličtinu :). Fazolky jsou fajn, to musím uznat, nicméně skript SQL to administrace, tak to je docela fakt klasa :).
Jakube, řekneš tedy, co to je za nástroj, vypadá to skutečně dobře, jestli by se daly i ty šablony nějak přizpůsobovat (nejen css), tak si troufám tvrdit, že to ušetří neskutečně hodně času. Což se hodí :)
Jakub Vrána :
Myslím, že moje angličtina by byla podobná :-).
Šablony se dají upravovat naprosto. Kromě stylu může šablona přepsat i jakýkoliv jiný soubor (třeba hlavičku a patičku). Navíc dostane vygenerovaný kód všech souborů k dozpracování (v PHP), takže si s ním pomocí běžných textových náhrad nebo jakýchkoliv jiných operací může dělat úplně cokoliv.
finc:
Abych byl upřímný, vypadá to moc hezky Jakube.
Asi by bylo lepší některé věci převést na pravou míru.
1. Daný tutoriál bych chápal spíše jako prezentační, tzn., že velmi často si z vygenerovaného kódu zachovám jen to použitelné (Entity)
2. Co se týče toho stylu, tak toto není plně pravda. Existují properties web.xml či další (podle zvoleného frameworku), které nám dokáží vytvářet šablony, či automaticky includovat soubory, jinými slovy, je to spiše o nastavení
3. Co se týče sloupce z číselníku, tyto věci jsou dost často nastavovány pomocí metody toString, která nám na základě vytvořeného objektu z Entity je schopna vrátit defaultní String.
4. U toho příkladu jsi nezmínil jednu zásadní a pro mě důležitou věc a to je právě "Entity classes from Databaze". Samotná ukázka totiž není jen o konečném view, ale zejména i o tom, že mi dokáže automaticky vytvořit Entity a Controllery Entit, které jsem schopen dále využívat. Říkám to zejména proto, že ORM v PHP moc dobře zařídit nelze, alespoň ne, na takové úrovni + automatické identifikace referenčních integrit, které jsou později dost důležitým aspektem každé větší aplikace nad DB.
Nakonec bych si dovolil jen takovou rýpavou otázku. Na jakých databázích jsem schopen to tvé řešení využít? :)
Jakub Vrána :
2. Vycházel jsem z předvedeného dema, kde se styl skutečně ručně kopíroval do všech souborů. Pokud to jde i jinak, asi to není tak přímočaré, aby se to dalo ukázat v demu, což svědčí o složitosti použití.
3. Opět vycházím z dema - sloupec z číselníku se přepisoval na několika místech.
4. Jak jsem psal - pojal jsem to jako cestu k vytvoření administračního rozhraní. Vtip je v tom, že s tímto nástrojem žádné Entity ani Controllery Entit nepotřebuji. Zohlednění referenčních integrit je samozřejmostí a svým způsobem to je samé jádro mého nástroje.
Momentálně můj nástroj běží na MySQL, protože to je databáze, kterou používám. Ale asi dokážeš nahlédnout, že rozšíření na jakoukoliv databázi, kterou podporuje PHP, by bylo víceméně triviální.
finc:
2. Vůbec to neznamená složitost použití. Spíše, že demo je něco jiného než praxe. Na druhou stranu, kvůli samotné přenositelnosti, je otázka, nakolik má být ten či onen view spojen se samotnou aplikací.
3. Souhlasím, je to přeci jen demo aplikace.
4. Já je také nepotřebuji, ale uvědomuji si, jak je práce snažší, ve chvíli kdy volám entity.getStredisko().getNazev(), atd. Prostě využití základních OO vlastností na relačních tabulkách má svoje kouzlo. Navíc přenositelnost je tak velká, že není jen v závislosti samotné aplikace, ale i mimo ni v jiném projektu.
Ono, ne vždy je implementace v jiných DB strojích jednoduchá, viz LIMIT v MySQL.
Jinak, když jsem koukal na to tvé video, viděl bych tam spíše použítí XML pro definici struktury. Možná by ten projekt byl pak o dost zajímavější. U ž z důvodu pozdějšího refactoringu. Nevím, kam až sahá tvoje implementace, ale určitě se občas stane, že DB strukturu již v DB mám a chci jen vytvořit danou aplikaci.
Přiznávám, že to tvé řešení je pro administrační rozhraní dost zajímavé. Kdyby jsi psal v Eclipse a udělal plugin pro eclipse na toto rozhraní, jistě by jsi si vysloužil slávu :)
Jakub Vrána :
XML by všechno jen zbytečně zkomplikovalo. Kouzlo použití komentovaného SQL skriptu spočívá v tom, že ho vyexportuji z databáze, doplním jen věci specifické pro administrační rozhraní a kdykoliv ho můžu zase použít pro vytvoření databáze.
V případě XML bych musel udržovat dva soubory a SQL na XML a zpět převádět nepoměrně komplikovaněji.
MiSHAK:
Pěkné demo :) Angličtina zlá :( Hlasitost řeči u tvého dema nízká :/
Jakub Vrána :
Taky jsem si dodatečně všiml, že je hlasitost u mého dema nízká. Ale už se mi s tím nechtělo babrat, navíc pro prohlížení v práci je nízká hlasitost lepší :-).
Hds:
Moc pěkné video, jestli se nepletu tak to dělá něco podobného jako scaffolding?
Václav Vaník:
Moc pěkné a líbivé :)
Chtěl bych se zeptat na čtyři věci:
1. jak máš vyřešeno, když je v tabulce velký počet sloupců, řekněme 20, to už je dost na to, aby tabulka byla hodně široká a nevešla se do prohlížeče?
2. máš v tvé aplikaci taky vyřešené vytváření filtrů (hledání podle jména, položka spadá do kategorie - referenční vazba)
3. relace M:N
4. vícejazyčnost
Hlavně body 3 a 4 (a především nedostatek času) mě odradily od toho, abych si napsal podobný klikátor :)
Petr Vytlačil:
Podívej se na CakePHP má tzv. baker se kterým se dají dělat divy. Ale tak jednoduché jak ukazuje svoje rešení J.V. to není.
Petr Duchek:
1) Tenhle problém podle mě ani inteligentně vyřešit nejde. Pokud má člověk 20 sloupečků v tabulce, tak je zalamovat, schovávat ani zmenšovovat nemůže. Musí navrhnout takový dyzajn, který umožní posouvání do stran nebo zredukovat informace v tabulce na nejnutnější a zbylé zobrazovat například jen u detailu. Osobně několik nápadů na řešení mám, ale smrdí to ajaxem nebo přinejmenším javascriptem.
Jakub Vrána :
Pokud chci všech 20 sloupců v tabulce skutečně zobrazit, vytvoří rozhraní běžnou tabulku, kterou si lze pomocí stylu upravit (nezalamovat, zmenšit písmo, ...). Každý typ má vlastní styl, takže třeba URL a e-maily osobně zobrazuji menším písmem. Pokud by se u nich měl zobrazovat třeba jen začátek a konec, dá se to řešit uživatelským dozpracováním - PHP funkce, která dostane text tabulky před tím, než se uloží.
kozotvor:
Napadlo mě přidat v SQL komentáři příznak, který před nebo za daným sloupcem vloží </tr><tr>, takže každý záznam bude ve dvou (nebo více řádcích).
Jestli to tedy nebude z nějakého důvodu problém.
A když už jsme u toho, třeba i příznak pro celou tabulku, aby ve výpisu opakovala hlavičky po každých X (např. 100) řádcích..
Jakub Vrána :
Tabulky, ve kterých je jeden záznam rozlezlý přes více řádků, jsou velmi nepřehledné, protože se pod sebou zobrazují nesourodá data.
Místo opakování hlavičky po X řádcích je podle mě lepší rovnou využít stránkování.
Jakub Vrána :
1. U každého sloupce jde nastavit, zda se má v tabulce zobrazovat.
2. Ano, vyhledávání všemi operátory včetně podpory fulltextových indexů a spojovacích tabulek M:N.
3. Relace M:N jsou podporovány. Pokud jsou jednoduché (dvousloupcové), pak se zobrazují jako seznam checkboxů nebo select multiple. Pokud má spojovací tabulka další sloupce, dají se editovat ve formě vložené tabulky.
4. Při kompilaci jde určit pevný jazyk (podporována je čeština a angličtina). Kromě toho jde jazyky přepínat dynamicky - řeší uživatelsky definovaná funkce, jejíž výchozí podoba je switch výrazů použitých v rozhraní (kromě toho je potřeba přeložit popisky tabulek a sloupců).
Václav Vaník:
Takže bych mohl poprosit o vytvoření ještě jedné ukázky, kde bys nám předvedl výše zmíněné advanced featurky?
optik:
Pekne, ale trochu mi to pripada jako reinventovat wheel :-) (to mam z java podcastu), pro admin rozhrani doporucuji dataface
http://fas.sfu.ca/dataface - cas bude mozna o neco malinko delsi, zasadni rozdil ale je ze to neni generator, ale framework, takze muzete mit autentizaci, psat si "triggery" a vubec si to ohybat do prava a leva. Je na diskuzi, zda pouzivat frameworky nebo
generatory (at uz v ruby/php/jave), oboji ma svoje pro a proti a dost casto frameworky ty generatory vyuzivaji (symphony, cakePHP, RoR).
Jakub Vrána :
Těžko jsem mohl začít znovuvynalézat kolo téměř o tři roky dřív než bylo vynalezeno (soudě podle data registrace na SF.net) :-).
Vlastní autentizaci a tvorbu „triggerů“ můj nástroj samozřejmě také podporuje. Rozdíl je v tom, že se nemusím učit API nějakého frameworku a prostě napíšu PHP kód.
finc:
To je problém PHP jako takového. Samotné frameworky nejsou žádným standardem, který by posvětil ZEND. Když začnu něco využívat, tak nemám nikde jistotu, že za rok či dva to nebude mrvé (nejsou peníze na další vývoj, vývojáři framework ohnuli to jiné úrovně, atd.). Osobně se mi v PHP také nechce učit žádné API, které mi nabízí cizí vendor.
JFK:
Prezentace je super. Preci jen myslim, ze neco podobneho existuje jako open source, napsane samozrejme v PHP od roku 2003, autor Bayer Ulrich. Nevim, nechci porovnavat, ktery generator je lepsi. Je prilozen jako plugin SimpleWebFont k programu DBDesigner. ... takze kdo chce vylepsovat .... mam moznost
Roman Strobl:
Ahoj, tato diskuse me celkem pobavila. Jsem autor dema JSF v NetBeans.
Par komentaru:
1. Nedavno jsem udelal nove demo Ruby v NetBeans, ktere ukazuje ze v Ruby on Rails to muze byt jeste jednodussi a rychlejsi:
http://www.netbeans.org/download/flash/jruby_…_rails.html
2. Proti PHP nic nemam, ba naopak, delal jsem v nem 5 let (tzn. dele nez v jave). Jako problem PHP vidim, ze neni vhodne na aplikace, ktere pisou vetsi teamy. Jinak je dobre (az na to ze neni tak ciste navrzene jako Java nebo Ruby).
3. Pro Mirka: Moji anglictine zda se lidi po svete rozumi, jinak si nedokazu vysvetlit proc melo treba jedno z mojich dem na Javalobby 15.000 unikatnich views. Takze co narozdil od kritiky moji anglictiny radeji natocit nejake demo a pomoct tak lidem co se uci programovat?
Jakub Vrána :
Demo je pěkné, ale jednodušší ani rychlejší mi to nepřijde. Především postrádám ukázku jakýchkoliv reálně potřebných vlastností alespoň v tom rozsahu, jako to bylo v tvém původní demu nebo lépe v mém - vazby mezi tabulkami, určení výchozího sloupce v tabulce, popisky sloupců používané v administračním rozhraní, řazení, stránkování.
Bez ukázky těchto vlastností by mé demo vypadalo zhruba takto: "Otevřete skript pro vytvoření databáze, stiskněte F7 a výsledkem se kochejte v prohlížeči."
Roman Strobl:
Mate pravdu, ze tyhle vlastnosti v demu chybi, kazdopadne tyto veci jsou v Ruby on Rails take velmi jednoduche.
U jakehokoliv frameworku je zasadni kolik lidi ten framework pouziva, takze i kdyz mate mozna genialni framework pro PHP, je potreba jej prosadit, aby jej lide zacali pouzivat. Pak to muze byt konkurence pro Ruby on Rails, Java frameworky ci jina reseni, ktera jsou dostupna zdarma.
V soucasne dobe lide mohou pouzit napr. Ruby on Rails, udelat aplikaci za 50.000 a neplatit nikomu nic, takze bez toho ze byste vas framework zverejnil je to krasne, ale jen pro par lidi. Treba by mel Zend o tento framework zajem - mozna jim ho muzete prodat? :)
Silvestr:
Taky jsem pomyslel na Zend, skoro hned. Ty nikdy, Jakube?
3rojka:
Pěkný nástroj pro php jsem ještě nikdy nic takového nevidě. To co říká Roumen o frameworcích je si pravda, al emít svůj framework o kterém člověk ví všechno a může si ho kdykoliv ohnout taky není k zahození. Je ale těžké hodnotit když nikdo neví co v tom je, ale i tak klobouk dolů.
Jinak s Roumenen musím ještě souhlasit s tou Magnolií je to opravdu výborný film, jeden z nejlepších které jsem viděl.
I.C.:
Taky už jsem přemejšlel, že bych se tu o tom zmínil. Ale jen čekám až mi přijde plná verze a zkusím nahtát totéž video v D4P. Zkoušel jsem to v trialu a trvalo to cca 20s, samozřejmě i s updatem pomocí ajaxu.
Armin:
Jakub Vrana: Ja osobne muzu doporucit:
http://www.screen-record.com/Jedna se o freeware ktery zachytava veskerou praci na PC, bere sice jenom 4fps, ale pro prezentaci bohate staci. Neexistuje zadna placena verze ktera zvladne vice obrazku za vterinu. Co se tyce vystupu, vygeneruje se .exe soubor. Neni zapotrebi zadny kodek ani nic, spusti to snad kazdy.
Antema:
Ten php generátor vypadá dobře, asi ho začnu používat :-)
Marty:
Článek jsem přečetl a video zkoukl :) Jen mě mrzí, že není u videa časový posuvník - pro důkladnější prohlédnutí.
Pokud bych chtěl udělat malé srovnání (které ovšem může vyjít úplně doprázdna, protože z tvého systému nemám žádný zdrojový kód, HTML podobu,...), takze:
1] Můj systém vychází z toho, že se objevuje čas od času potřeba vložit do kódu něco, co je neuniverzální, například funkce group_concat(), concat(), ... v SQL příkaze pro zobrazení dat / editaci. Na tomto stále ještě pracuji. Jde to nějak jednoduše v tvém systému?
2] Pokud přibyde do tabulky nový sloupec (nejsem zastánce názoru, že hned na počátku je tabulka navržená tak, jaká je reálná potřeba, protože reálné potřeby se mění), tak z videa bych soudil, že musíš dělat znovu kompilaci. Co se však pak stane s případnými změnami ve vytvořených PHP souborech (např. někdo se rozhodne si někam něco dopsat, změnit textový odkaz na obrázkový, ...) ?
3] Je v tvém systému modul na logování událostí?
4] Pokud bys chtěl změnit formulářový prvek u daného sloupce, tak používáš nějaký speciální zápis v komentáři k sloupci?
5] Některé atributy v HTML nemají obdobu v CSS, jak řešíš tyto případy?
6] Tvůj systém je rozhodně elegantní a zřejmě lepší než můj, škoda, že jsi neukázal, co vše umí, očekávám, že když na něm pracuješ už nějaké čtyři roky, tak jsi nám ukázal pouze část toho, co to umí :-)
Jakub Vrána :
1. Volání funkcí až na definované výjimky (např. SHA1) možné není.
2. Změněné soubory se nepřepisují a uživatel je na to upozorněn. Ideální je vygenerované soubory přímo neměnit a upravit je pomocí postprocess() funkce, takže změny zůstanou zachovány i při přegenerování.
3. Ne, ale u jednoho projektu jsem to vyřešil jednoduchou změnou funkcí mysql_insert() a spol. Do logu se zapisuje i to, co bylo v tabulce původně.
4. Ne, mapování typů na formulářová pole je pevné. Změnit se dá jedině to, jestli se vazby M:N budou zobrazovat jako <select multiple> nebo řada checkboxů.
5. Otázce bohužel nerozumím.
6. Ano, je to pouze zlomek možností. Větší demo a web o programu chystám.
Marty:
1] Přidání této informace do komentáře ke sloupci by bylo jednou možností, pokud by se to dávalo kamkoli jinam, tak to znamená znovu psát jméno sloupce a to je zbytečné psaní navíc.
2] Mě vždy víc vyhovovalo pouhé měnění parametrů, kompilace je z hlediska mých potřeb nadbytečná, protože často doupravuji administraci na webu tak, že mám v PSPadu otevřené FTP daného serveru a uložím soubor, čímž se mi uloží soubor jak na server, tak do složky na mém HD. Ušetřím tedy kopírování kompilovaného kódu.
3] Tímto způsobem řeším přepínání mezi Mysql a Mysqli, zvykl jsem si na svou funkci: $insert_id=xquery("nějaké sql", "insert_id"); :-) Ve svém systému jsem to řešil daným výchozím zápisem (původní hodnota » nová hodnota), který je možné upravit v nastavení.
5] například: <input type="text" disabled="disabled" />, atribut disabled tuším v CSS není. (toto je taková předzvěst práv pro jednotlivé uživatele, v mém systému často nastavuji různé hodnoty pro různé parametry pro různá práva uživatelů)
6] už se těším :), budu pilně pracovat na svém systému, aby to bylo alespoň trochu konkurenceschopné :)
Jakub Vrána :
2. Principiálně vzato by se to dalo upravit tak, aby to soubory negenerovalo resp. je dokázalo automaticky přegenerovat. Ale generované soubory mají své výhody – jednak je možné je zcela libovolně upravit o vlastnosti, které program nepodporuje, a jednak je můžeš dát klientovi bez toho, abys mu dával celý framework.
5. Konrétně zakázání editace řeší příznaky UNEDITABLE, UNCHANGEABLE. Pokud sloupec nemá komentář, tak nebude vidět vůbec.
Marty:
Důvod, proč nechceš vydat svůj framework pod Apache licencí (jako například JUSH) nebo jinou podobnou licencí, je ten, že si ceníš myšlenky (které nejsou zveřejněné na tvém blogu), a nebo ten že nevěříš duálním licencím (komeční a nekomerční)?
Jakub Vrána :
Je to hezké, ale příšerně ukecané. Když pominu desítky vygenerovaných souborů, tak mě odrazuje především to, že stejnou věc musím psát na několik různých míst - zvlášť do databáze, zvlášť do XML skriptu popisujícího databázi, zvlášť do popisu jednotlivých polí. Validace se píše ještě jinam a když chci místo author_id zobrazit jeho jméno, musím si to napsat sám v PHP kódu. Skripty pro každou tabulku se navíc generují zvlášť.
Adminer má všechno na jednom místě - když přidám sloupec, připíšu jeden řádek do jednoho souboru a hotovo.
Funkčně se mi zdá Symfony poněkud chudší, ale některé věci má i navíc (přizpůsobení textů na jednotlivých stránkách - je to maličkost, které si člověk možná ani nevšimne, ale přitom stojí dost práce, takže bych se s tím stejně osobně asi nedělal).
kriplozoik:
Opravdu pěkné.
1) Je možné řadit záznamy kliknutím na pole v hlavičce tabulky?
2) Dá se v tvém rozhraní v tabulce rozlišit NULL a prázdný řetězec?
3) Co podpora GROUP BY, a nebo pohledů (VIEW)?
4) Jak je to s autorizací uživatelů (jednoduchá, stratifikovaná, kde/jak se ukládají údaje o uživatelích)?
5) Když do sql přidáš/odebereš/změníš sloupec nebo celou tabulku, co se stane s daty? Chci říct - není problém smazat tabulky a vytvořit strukturu tabulek spuštěním sql příkazu, ale tím se smažou data. To nějak ze skriptu spouštíš "ALTER TABLE" nebo přesypáváš data z původní tabulky do té změněné?
6) A jen tak pro inspiraci, např. M$ Access (ne, že bych ho nějak vyznával) má
* jakousi primitivní kontrolu dat (jinými slovy, lze u datového typu definovat podmínku pro hodnotu, když nevyhovuje, aplikace nedovolí hodnotu vložit)
* masku pro vkládání dat (v prostředí PHP by bylo možno využít regulární výraz, který je ještě mocnější než tahle maska)
* krom názvu sloupce ještě poznámku, která může sloužit jako dovysvětlující prvek nebo krátká instrukce
Jakub Vrána :
1. Ne. Způsoby řazení se nabízí podle vytvořených indexů, což je možné upravit. Výhoda spočívá v tom, že je možné řadit podle více sloupců (např. skupina, pořadí).
2. Ano. Pokud má sloupec příznak NULL, tak se u políčka zobrazuje zaškrtávátko s hodnotou NULL. U neřetězcových datových typů (čísla, datum) se za NULL považuje prázdný řetězec.
3. Není.
4. Systém má tři způsoby zabezpečení - bez autorizace, jedna pevná autorizace nebo tabulka uživatelů. Informace o přihlášenosti uživatele se ukládá do session proměnné, heslo je uloženo zahešovaně.
5. Součástí nástroje je skript alter_tables.php, který načte skript, porovná ho s databází a vypíše/provede potřebné změny v databázi.
6. Nástroj umožňuje hodnoty kontrolovat pomocí SQL konstrukce CHECK. Podporované jsou běžné operátory.
Snadno by se dala doplnit i podpora operátoru REGEXP, ale zatím jsem to nepotřeboval.
Poznámka se parsuje (druhý komentář sloupce: -- název sloupce -- poznámka), ale momentálně se v administraci nezobrazuje, takže slouží spíše jako interní poznámka pro tvůrce skriptu.
štíhloprd:
6) Myslím, že o poznámkách (zde asi ve formě atributu title="") by bylo záhodno uvažovat. Leckdy z názvu sloupce (i jeho obdoby v českém jazyce) nemusí být známo, jak je myšleno, že má být zadán. Někdy alespoň kratičká věta typu "zadejte ve formátu xyz" může uživateli značně pomoct, aby nebyl zmatený.
7) Ještě mě napadá - je nějak omezeno, kolik se toho ve výpisu může jako obsah jednoho pole objevit? Např. PhpMyAdmin implicitně u dlouhých textů zobrazí prvních cca 100 znaků a "..."
8)Umožňuješ uživateli na data před uložením spustit MD5, SHA1.. Umožňuješ taky ENCODE() a DECODE()?
9) Někdy se to, co se hodí zobrazit ve výpisu tabulky a to, co je v ní skutečně uloženo, může lišit (což není špatně ani dobře, prostě to tak někdy může být). Přemýšlel jsi umožnit jako výpis zobrazovat výsledek VIEW, kde by byla možnost si výsledek realizovat k obrazu svému (tzn. využít přímo funkce MySQL, které výpis -tam, kde bude potřeba- upraví, (CONCAT(), IF(), ELT(), různé skupinové...) ?
10) Nevím, jestli je to tu řečeno nebo ne, ale je potřeba uložit kromě klientem zadaných tabulek ještě nějaké pro správu (např. o uživatelích, kteří mají k adminerovi přístup)?
Jakub Vrána :
6. Z názvu sloupce by uživateli mělo být jasné, co se do něj má vyplnit. Pro vyplňování by se měly používat vestavěné datové typy (z pohledu Adminera, tedy např. včetně PSČ nebo URL), u kterých je formát uveden přímo Adminerem.
7. Zobrazuje se vždy kompletní obsah pole. Dlouhé texty je obvykle lepší ve výpisu vůbec nezobrazovat a zobrazit je jen v detailu.
8. Podporované jsou jen dvě zmíněné hashovací funkce. ENCODE() obvykle stejně není implementovaná bezpečným způsobem a lepší je použít http://php.vrana.cz/ukladani-citlivych-informaci.php#openssl.
9. O využití pohledů jsem dosud neuvažoval.
10. Žádné tabulky navíc nejsou potřeba. Tabulka se seznamem oprávněných uživatelů může existovat, její strukturu si ale můžeš navrhnout sám (stačí u sloupce s přihlašovacím jménem zadat příznak {LOGIN}) a je běžnou součástí administrace.
MoDDO:
Ahojky pratele, a pracoval nekdo v CodeCharge Studio 3.1, take velice jednoduche toto v tom vytvorit.
head:
Hmm videa som si este nepozrel, ale nieco podobne podla mna poskytuje QCodo, http://www.qcodo.com/, tento framework obsahuje Code Generator, ktory okrem automatickeho vytvorenia tried pre pracu s datami v DB, vytvori aj takzavane form_drafst, ktore sa daju pouzit na vkladanie dat a prehliadanie dat v DB a jednoduchymi zmenami sa da z toho spravit rozhranie pre spravu...
piler:
Zdravicko,
ako pokracuje vyvoj tohto rozhrania?
Ladislav Jelinek:
Zdravim, Tvuj framework, Jakube, je docela zajimavy, s tim marketingem bych Ti mozna mohl pomoci, ale myslim, že nejlepsi marketing je hodit to mezi lidi. Cim vice uzivatelu jej bude pouzivat, tim vetsi balik pak od Zendu dostanes :)
Pokud jde o CRUD generatory a helpery, muzu poradit Pork, Adroit, AutoCRUD, PhpReady, PhpSimpl a mohl bych pokracovat az jiz zminenemu generatoru od Maestro Group.
X-Ray:
Zajímalo by mě, jestli by si mi mohl napsat nejaky zdrojovy kod, abych mohl vytvorit podobne komentare, do ktereho ted pisu.Muj Email : DAN3DA@email.cz nebo ICQ: 483 104 828 případně Jabber: X-Ray@jabbim.cz
marek:
Zdravim, zkouseli jste uz nekdo Django? Lepsi a komplexnejsi tvorbu admin rozhrani jsem nikde jinde nevidel.
Ostatne ohybat SQL prikazy pro generovani admin rozhrani mi prijde zvracene :-).
Jakub Vrána :
Django používám denně. Automaticky vytvořené administrační rozhraní není špatné, ale Adminer se mi používá líp a snadněji udělám složitější věci.
Michal:
Adminer je již jiný projekt a chtělo by to v článku upravit.
Diskuse je zrušena z důvodu spamu.