Adminer Editor
Školení, která pořádám 
- 29.9.2010 Návrh a používání MySQL databáze
- 30.9.2010 Úvod do PHP
- 1.10.2010 Programování v PHP 5
- 4.10.2010 JavaScript a AJAX
- 5.10.2010 Knihovna jQuery a AJAX prakticky
- 6.10.2010 Výkonnost webových aplikací
- 7.10.2010 Konfigurace a výkonnost MySQL
- 8.10.2010 Bezpečnost PHP aplikací
Do druhé verze svého nástroje pro správu MySQL databáze Adminer připravuji samostatnou aplikaci Adminer Editor, která slouží pouze pro zobrazení a editaci dat. Hlavní smysl aplikace je ten, že ji můžete svěřit do rukou i běžným uživatelům bez obavy, že by vám poškodili strukturu databáze.
Od Admineru se Editor liší v několika důležitých bodech:
- Uživatel se nepřihlašuje pomocí přihlašovacích údajů MySQL, ale vlastní kombinací přihlašovacího jména a hesla.
- Nelze vybrat databázi, se kterou se má pracovat, ale je pevně nastavena jedna databáze.
- Pro popisky tabulek a sloupců se používá komentář, pokud je vyplněn.
- Nezobrazují se provedené SQL příkazy (ty jsou uvedené jen v HTML komentářích).
Cílem aplikace je zpřístupnit většinu funkčnosti, která je k dispozici v aplikaci Adminer Pro, která administrační rozhraní generuje do PHP skriptů.
Zpočátku jsem také přemýšlel o tom, že bych Editor integroval do Admineru, ale nakonec jsem zvolil dvě oddělené aplikace. Obě jsou totiž určené pro jinou cílovou skupinu a i když správce databáze také občas potřebuje pracovat s daty, tak to obvykle zvládne i v nízkoúrovňovém rozhraní. Naopak zadavatel dat nesmí mít ke struktuře databáze přístup. Výhodné to je také kvůli velikosti souborů s aplikacemi.
Přemýšlím také, co odstranit z výpisu a editace dat, aby se Editor dále zjednodušil:
- Seznam sloupců ve výpisu by asi uživatel neměl mít potřebu měnit (půjde určit, které sloupce se ve výpisu nemají zobrazovat), ale může chtít data seskupit.
- Data určitě bude chtít uživatel prohledávat, ale asi nebude chápat operátory jako
NOT LIKE. - Data nejspíš bude chtít řadit (i když výchozí způsob řazení by mohl jít určit), ale možná nebude potřebovat řazení podle více sloupců.
- Hromadné operace s daty jako jsou úprava, klonování a mazání jsou určitě užitečné i v Editoru.
- Export a import se také může hodit, ale bude stačit formát CSV. Naopak by mohl jít změnit oddělovač, protože uživatelé českých Windows si ho nebudou umět změnit z výchozího středníku.
Některé věci určené pro Editor jsem zatím přidal i do Admineru a přemýšlím, jestli je tam nechám:
- Možnost hromadného odeslání e-mailové zprávy na vybrané adresy
- Při výpisu tabulky dochází ke kontrole, zda některý sloupec obsahuje e-mailovou adresu. Pokud je detekce úspěšná, tak se zobrazí formulář pro odeslání e-mailu.
- Zobrazení odkazů na související záznamy
- Například u alba se zobrazuje odkaz na písničky, které na tomto albu jsou.
Závěr
Pro Editor je zatím k dispozici jen demo a zdrojové kódy v SVN, ale už teď mě zajímá, co byste v takovém nástroji chtěli nebo naopak nechtěli. Cílem je vytvořit aplikaci, díky které by nebylo potřebovat ručně vytvářet běžné administrační rozhraní. Nutnou podmínkou pro tento cíl je dobrá rozšiřitelnost nástroje, o které ještě napíšu.
Diskuse
Bednee:
Vidím zádrhel při zadávání hodnot, které jsou IDčka z jiné tabulky (foreign key), v demu Album - Interpret. BFU toto nebude schopný pochopit. V tomhle místě by byl asi nejlepší dropdown pro výběr hodnoty.
Jakub Vrána:
To se samozřejmě ještě změní, jde o velmi ranou verzi. Měl by to být jeden ze zásadních rozdílů. Pro jistotu uvádím interní TODO:Popisné sloupce
Skryté sloupce
Formát data
Validace dat
Vazební tabulky
Pořadí tabulek v navigaci
Odhlášení
Konkrétně tohle spadá pod Popisné sloupce. Spíš než dropdown tam ale bude nejspíš našeptávač, protože odkazované tabulky mohou být velké.
crempa:
a nebo popup (ajax popup) s tabulkou pro vyber zaznamu ciziho klice, u naseptavace muze byt problem jak se rozhodnout podle ktereho sloupce se bude naseptavat... Jakub Vrána:
Ano, já i tomuhle říkám našeptávač. Varianta s tabulkou bude nejspíš v Admineru, v Editoru půjde označit Popisný sloupec (nebo se automaticky vybere) a bude se hledat jen v něm.
Jakub Vrána:
To je dobrý nápad, dokonce by ani nebylo zvlášť těžké to udělat. Stačilo by si před změnou a smazáním zapamatovat původní hodnotu a po uložení tu novou.Jenom kam to dát do uživatelského rozhraní? Provedení unda by asi mělo být potvrzené a pak by mělo být i redo. A stačil by jeden krok nebo více?
ZtF:
Napada me to resit pomoci nejakeho stacku vektoru zmen (kde by byly implementovany patricne metody undo a redo). Ceho se ale desim v tomto pripade je synchronizace pristupu (a pochybuju, ze by se chtelo implementovat zamky/semafory/transakce). Jakub Vrána:
Ptal jsem se na uživatelské rozhraní - jak funkci zpřístupnit lidem.
Jakub Vrána:
Dobrý nápad. Rozhodně chci mít tabulku s uživatelskými právy a dva základní režimy přístupu - buď práce se vším nebo jen s vlastními objekty. Ale podrobnější určení práv se bude také hodit.
Jakub Vrána:
Autorizaci nechám zcela na uživatelském rozšíření. Adminer a Editor prostě zavolají metodu login() a podle toho, co vrátí, tak zobrazí buď stránku nebo chybovou hlášku.
Jakub Vrána:
V Admineru si člověk může nastavit libovolnou AND podmínku, do Editoru bych to chtěl zjednodušit. Přemýšlel jsem o textovém vyhledávání bez omezení sloupce (to umí i Adminer). U dat a čísel je rozsah dobrý nápad.
Jakub Vrána:
Nechápu souvislost se Scaffoldingem.
Kajman:
Možná by stálo za zvážení, zda by se u tabulek se sloupcem, kde je nějaké pořadí, dalo nadefinovat, že uživatel může jednoduchým klikáním posouvat řádky nahoru a dolu. Jakub Vrána:
To by bylo užitečné. Otázka je, jaké pro to udělat uživatelské rozhraní, protože přesouvat to po jednom šipkami z konce na začátek by byla pěkná otrava. Adminer Pro to řeší prostě tak, že dovolí zadat nové pořadí a ostatní prvky přesune tak, aby vznikla souvislá řada.Adminer Pro taky podporuje traverzování kolem stromu - u toho se pořadí určí tak, že se vybere, za jakým prvkem se má ten editovaný zobrazit.
Kajman:
Takhle by to asi stačilo. Ale možná by se mohly zkombinovat obě varianty.Marek Hrabě:
Možná by bylo zajímavé udělat nějaký online generátor, kde si každý vybere, co bude chtít v jeho Editoru. Myslím tím rozdělit aplikaci na jakési moduly, které se do aplikace integrují před stažením dle volby...U "propojených tabulek" jsem také pro nějaký druh našeptávače - určitě bude užitečný...
Jakub Vrána:
Co by to mělo být za moduly? Editor chci výhradně pro práci s daty, to znamená výpis, přidání, editace, mazání. Rozdělovat tohle na moduly mi nedává smysl a doplňovat nic dalšího tam nechci.
Šimoník:
Proč se mi v adineru zobrazuje text :Podzimní turistika v Roháèích, tak to už je u nás tradice. Letos tomu není jinak..
má tam být v Roháčích.
Já když ze své databáze vypisuji, tak je to OK. Zkoušel jsem i v prohlížeči měnit kodové stránky ale nepomohlo to.
Díky
Jakub Vrána:
Pokud jde o MySQL >= 4.1, tak je problém s kódováním. Přečti si http://php.vrana.cz/mysql-4-1-kodovani.php
Šimoník:
Databáze jeVerze MySQL: 5.0.32-Debian_7etch10-log přes PHP extenzi MySQLi.
Článek jsem četl. Jak ale zjistím, co za kodování je ve skutečnosti v databázi?
Databáze je utf8, stránky s odesílacím formulářem pro databázi pak windows1250. Bohužel jsem při tvorbě skriptu nic ohledně kodování nenastavil a teď nevím, jak jsou vlastně data v databázi uložena.
Lze tedy nějak i dodatečně zjistit skutečné kodování a následně správného zobrazování v Admineru?
Jakub Vrána:
Ano, v editaci databáze i struktury tabulky se použité kódování zobrazuje a je možno ho změnit.
Šimoník:
Jako myslíte změnit na cp1250? To jako bez nějakých konverzí atd? Nedojde k nějakému zmatku a poškození textu?Pak by se to mělo v admineru zobrazova už správně?Šimoník:
Díky. Bylo to trochu složitější. Jak již bylo tady uvedeno, když někdo, třeba jako já ,dlabe na nastavení databáze, pak se dočká toho, že posílá data win1250, mysql si myslí, že jsou latin1 a uloží je jako uft8 pak je převod do normálu trochu komplikovanější :-)Takto jsou totiž default nastaveny servery hostingu C4.
Použil jsem návod z builderu :
1) Vytvořit dočasnou tabulku se stejnou strukturou
DROP TABLE IF EXISTS pokus;
CREATE TABLE pokus LIKE tabulka;
2) Změnit character set na ten, který dává použitelné výsledky (v mém případě latin1) Prostě ten, který získáte z výpisu serveru character_set_connection
ALTER TABLE pokus MODIFY username varchar(200) CHARACTER SET latin1;
3) Nakopírovat do nové tabulky data z té původní
INSERT INTO pokus SELECT * FROM tabulka;
4) Změnit definici sloupečků na správný charset beze změny dat jako takových:
ALTER TABLE pokus MODIFY username BINARY(200);
ALTER TABLE pokus MODIFY username VARCHAR(200) CHARACTER SET cp1250 /* pripadne NOT NULL DEFAULT '...' AUTO_INCREMENT */;
Pozn. pro text pak blob
5) Propsat opravená data do původní tabulky
DELETE FROM tabulka;
INSERT INTO tabulka SELECT * FROM pokus;
6) Smazat dočasnou tabulku
DROP TABLE pokus;
Uff. Už mi adminer funguje. Je perfektní.
Šimoník:
Lze nějak v Admineru vytvořit ze stávající tabulky příkaz sql pro tvorbu dané tabulky? Jakub Vrána:
Pomocí exportu.
Šimoník:
Ale to se exportuje včetně dat. Já jsem myslel pouze strukturu.Jan "Panda" Smitka:
U exportu si můžeš dole v tabulce zatrhat, jaké tabulky chceš exportovat a jestli chceš exportovat i jejich data. Pak se samozřejmě exportuje jen struktura. Jakub Vrána:
Přesně tak. Případně i nahoře se dá vybrat, jakým způsobem se bude exportovat struktura a jakým data. Jeden ze způsobů je i nijak.
Šimoník:
Ach jo,kdybych nebyl slepý. Já jsem viděl export pořád jen pod tabulkou a ne vedle SQL.Šimoník:
Tak jsem se radoval předčasně. Adminer mi krásně zobrazuje češtinu, na stránkách je taky v pořádku. Ale když dám vyhledat tak je problém, data se nenajdou. Místo rovnosti musím dát LIKE a za hodnotu ještě %.Tak teď už opravdu nevím, jak mám data v databázi uložena.
Existuje nějaká způsob, jak to dát dopořádku?
Díky
MaT:
No jak, asi s mezerami, nebo nějakými jinými whitespace znaky na konci...Šimoník:
Proč, prosím mi v admineru nefunguje vyhledávání podle češtiny, když se v admineru čeština zobrazuje správně.Jan "Panda" Smitka:
Vyhledávání není moc záležitostí Admineru, spíš databáze a správně položeného dotazu. Jaké máš teď nastavení charsetů v tabulce (popř. u sloupců) a jaký dotaz pokládáš?Šimoník:
Z admineru jsem vyexportoval dotaz :SET NAMES utf8;
SET foreign_key_checks = 0;
SET time_zone = 'SYSTEM';
DROP TABLE IF EXISTS `komentare`;
CREATE TABLE `komentare` (
`id` int(10) unsigned NOT NULL auto_increment,
`rodic` int(10) unsigned NOT NULL,
`autor` varchar(45) collate cp1250_czech_cs NOT NULL default '',
`datum` varchar(50) collate cp1250_czech_cs NOT NULL default '',
`obsah` text collate cp1250_czech_cs NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=38 DEFAULT CHARSET=cp1250 COLLATE=cp1250_czech_cs;
INSERT INTO `komentare` (`id`, `rodic`, `autor`, `datum`, `obsah`) VALUES
('1', '163', 'ČPBBT', '09-04-2009 20:31:25', 'Jsem nemocný, nejedu. Ach, jak já trpím :-)');
trochu mě překvapuje, že tam je utf8. Když to změním na
cp1250 tak vznikne paskvil. Čeština je OK ale dotaz ba ČPBBT nefgunguje.
Nastavení databáze je :
character_set_client utf8
character_set_connection latin1
character_set_database latin1
I když to zkusím v PHP kde dám MYSQL_QUERY(" SET NAMES 'cp1250'");
a pomocí insert dám data do databáze, tak stejně nejde vyhledávat podle češtiny.
Tady je kousek php kodu :
<?php include "fce.php"; ?>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=windows-1250">
<meta name="generator" content="PSPad editor, www.pspad.com">
<title></title>
</head>
<body>
<?php
spojeni();
$prikaz="INSERT INTO komentare (rodic,autor,datum,obsah) VALUES ('163','ČPBBT','09-04-2009 20:31:25','Jsem nemocný, nejedu. Ach, jak já trpím :-)')";
@$set = MySQL_Query($prikaz);
if (!$set):
echo mysql_error();
echo "Chyba při ukládání dat do databáze. Kontaktujte prosím webmastera ";
break;
endif;
?>
Jsem z toho už úplně paf.
Šimoník:
Teda, může mi někdo vysvětlit, proč pro následující nastavení :character_set_client utf8
character_set_connection latin1
character_set_database latin1
character_set_filesystem binary
character_set_results utf8
character_set_server latin1
character_set_system utf8
character_sets_dir /usr/share/mysql/charsets/
collation_connection latin1_swedish_ci
collation_database latin1_swedish_ci
collation_server latin1_swedish_ci
zabralo až nastavení v php scriptu :
MYSQL_QUERY("SET NAMES 'cp1250'");
Data jsou cp1250
a tabulky musí být nastaveny na utf8 !!!!
Jestliže jsou na cp1250 tak nefunguje vyhledávání podle češtiny i když ta se zobrazue správně.
Jakub Vrána:
Pozor na to, že pro cp1250 se používá porovnávání cp1250_czech_cs, které rozlišuje velikost písmen.
Jakub Vrána:
SET NAMES utf8 tam je proto, že Adminer data exportuje v UTF-8.
Marek Turnovec:
Nějak jsem stále nepřišel na to, jak se do toho Adminer Editoru přihlásit. Asi jsem úplně blbej... Má to někde nějakou dokumentaci? Tady se píše, že místo autentizace z MySQL se uživatel přihlásí "vlastním kombinací jména a hesla". To je co? Kde je mám vzít? Jakub Vrána:
Pokud používáš Editor bez jakéhokoliv rozšíření, tak se jméno a heslo nekontroluje. Přihlašovací údaje k databázi se vezmou z konfigurace (např. mysql.default_*).Editor je nicméně určen hlavně k rozšířování. Jednoduchý příklad a kompletní dokumentace je na http://www.adminer.org/cs/extension/. Zajímat tě budou hlavně metody credentials(), login() a možná ještě database() – pokud máš k dispozici více databází.
