Konvence místo konfigurace

Školení, která pořádám

Adminer Pro hodně sázel na konfiguraci. Schválně se podívejte do dokumentace, co všechno lze nastavit. Adminer Editor se naproti tomu snaží vycházet z konvence. Co si pod tím představit?

Adminer Pro dovoluje pomocí příznaku určit, zda sloupec obsahuje e-mail nebo obrázek. Editor to jednoduše detekuje podle dat.
V Admineru Pro je možné určit, které tabulky a sloupce se mají v rozhraní zobrazovat. Editor bez jakýchkoliv úprav zobrazuje všechno, ale s výchozí úpravou, která je přímo součástí projektu, zobrazuje jen tabulky a sloupce s komentáři.
Dlouho jsem přemýšlel, jakou konvenci použít pro zobrazení sloupců ve výpisu tabulky (Adminer Pro uvozuje komentář skrytých sloupců znakem &), až mi kamarád poradil zobrazovat ve výchozí úpravě prostě prvních pět sloupců v tabulce. Některé tabulky jsem kvůli tomu musel trochu předělat (sloupce uvádím v pořadí, v jakém se data do tabulky dostávají), ale kupodivu tato jednoduchá konvence funguje docela dobře.
V Admineru Pro se musí určit, s jakou databází se má pracovat. Naproti tomu Editor prostě vezme první dostupnou databázi – na většině hostingů je k dispozici jenom jedna, takže to splní účel dostatečně.
V Admineru Pro je nutné označit popisný sloupec – to je ten sloupec, který chceme zobrazovat při odkazech do dané tabulky. Editor vezme prostě první varchar.
Adminer Pro v základu řadí podle prvního definovaného indexu a pomocí příznaku lze určit, zda se má řadit vzestupně nebo sestupně. MySQL bohužel neukládá informaci o tom, s jakým příznakem byl index definován, takže Editor jednoduše všechno řadí vzestupně, jen datumy sestupně.
Až budu v Editoru dělat validaci dat, udělám to podle názvu sloupců – obsahuje název sloupce slovo „email“? Pak se do něj asi bude zadávat e-mailová adresa. Obsahuje slovo „html“? Zobrazí se pro něj HTML editor. Obsahuje slovo „sha1“? Tak to asi bude haš zadané hodnoty – to by se možná dalo vyřešit i detekcí datového typu char(40).

Důležité je zmínit, že jde pouze o základní konvenci – pokud někomu nevyhovuje, může si pomocí vlastního rozšíření určit svoji konvenci nebo třeba systém bez konvence, který pro každou tabulku bude definovat popisný sloupec ručně. Pomocí rozšíření je možné přidávat i další funkčnost – např. kdybych si chtěl doplnit detekci URL adres, tak nepotřebuji kód Editoru nijak měnit. Systém je tedy robustnější, protože pomocí rozšíření lze doplnit funkčnost, na kterou by konfigurace nestačila. Díky tomu také zůstávají komentáře v databázi čisté a není potřeba je psát třeba jako &Potvrzeno {DISABLING = 0, SEARCH}. Další výhoda je, že pokud člověk používá danou konvenci, tak se nemusí nic učit a může nástroj začít rovnou používat.

Jakub Vrána, Adminer, 31.7.2009, diskuse: 6 (nové: 0)

Diskuse

Kačer:

Pokud bude první databáze "information_schema" (na některých hostinzích ji v phpMyAdminu vidím), bude Editor pracovat s ní, nebo ji přeskočí?

31.7.2009 10:43:20

Jakub Vrána :

Samozřejmě ji přeskočí.

31.7.2009 12:13:17

Robert Vlach:

Setkal jsem se také s tím, že některé webhostingy vytvářejí implicitně kromě hlavní databáze zkušební databázi test, temp nebo tak nějak.

31.7.2009 13:20:59

Jakub Vrána :

To je samozřejmě možné, sám mám na serveru taky desítky databází. Konvence prostě vezme první a komu to nevyhovuje, tak si napíše jednořádkovou metodu, která vrátí tu správnou. Výhoda je, že na rozdíl od konfigurace může být logika této metody libovolná.

31.7.2009 13:28:04

Marek Hrabě:

Jak to s Editorem vypadá časově? Vypadá to opět na perfektní nástroj a chtěl bych ho zapojit do pár mých aplikací. Máš tušení, kdy by to mohlo dopadnout, Jakube?

8.8.2009 10:51:05