Webdesign

Představuji k volnému použití (licence GNU GPL) jednoduchý dababázový layer, který je určen pro MySQL 3.23 až 4.0 (mysql), MySQL 4.1 (mysqli), SQLite a PostgreSQL.

Tento layer je záměrně psán neobjektově. Proč? Je určen pro úpravu starých skriptů, které jsou natvrdo psány pro MySQL 4.0, aby co nejdříve fungovaly s DB-layerem (na libovolné open-source databázi).

Názvy funkcí layeru jsou navrženy tak, aby byly shodné se syntaxí MySQL funkcí, jen místo mysql budete psát sql, tedy například místo mysql_connect budete psát sql_connect. Teoreticky je tak možné na Vašem skriptu udělat hromadný search-and-replace slov mysql_ na sql_, a Vaše aplikace by měla fungovat s DB-layerem.

Pro nový vývoj je samozřejmě vhodnější použít DB-layer objektový, uvedu jej zde zítra.

Zdrojové kódy layeru jsou zde.

Použití layeru pro MySQL:

Typické použití pro MySQL 4.1 bude spočívat ve vytvoření souboru config.php s tímto obsahem:

Příklad pro SQLite:

Prefix tabulek:

Uvedený skript počítá rovněž s prefixem tabulek. Ten je velice důležitý, typicky máte na web-hostingu povolenou jen jednu MySQL/PGSQL databázi, a potom je nezbytně nutné jednotlivé instalace stejné aplikace odlišit právě prefixem v názvech tabulek.

Použití tohoto skriptu?

Náš index.php může vypadat například takto, a bude fungovat na MySQL 4.0, MySQL 4.1, SQLite a PostgreSQL:

SQLite je ještě lepší, než jsem čekal. Nejenom má v 200KB podporu pro triggery a views, ale její SQL příkazy a funkce je díky integraci s PHP možno rozšiřovat o libovolné callbacky (na PHP funkce).

Pokud tedy SQLite nemá funkci UNIX_TIMESTAMP(), která převede string na UNIX-like datum (počet sekund od 1.1.1970), tak si ji nadefinujete v PHP, registrujete pro SQLite, a používáte ji potom zcela normálně ve Vašich SQL příkazech.

Například takto můžete SQLite rozšířit o podporu pár funkcí, které oproti MySQL nativně nemá:

sqlite_create_function($db,'UNIX_TIMESTAMP','strtotime',1);
sqlite_create_function($db,'NOW','time',0);
sqlite_create_function($db,'DAYOFMONTH','_day',1);
sqlite_create_function($db,'MONTH','_month',1);
sqlite_create_function($db,'YEAR','_year',1);
sqlite_create_function($db,'SUBSTRING','substr',3);

function _day($time) {
	return date("d",strtotime($time));
}
function _month($time) {
	return date("m",strtotime($time));
}
function _year($time) {
	return date("y",strtotime($time));
}

V PHP 5 je zahrnuta nativní podpora pro SQLite. SQLite je velice zajímavá databáze. MySQL 4.1 má 25MB, zatímco SQLite má jen 200KB (ano, dvěstě kilobajtů). Navíc, nemusíte ji nijak instalovat, pokud máte PHP 5, máte i SQLite. Dlouho jsem tuto databázi ignoroval, nicméně, včera jsem si napsal databázový layer pro BLOG:CMS, podporující MySQL 4.0 (mysql) a MySQL 4.1 (mysqli), a začal jsem přidávat i SQLite.

Musím říci, že SQLite je fantastická databáze. Jaké jsou její hlavní výhody?

• SQLite se nemusí instalovat, je integrována přímo v jádře PHP 5,
• SQLite umí to samé, co MySQL, a navíc má podporu pro transakce (což MySQL pro MyISAM engine nikoliv), views a triggery (!),
• SQLite umí in-memory tabulky, což je fantastická věc pro dočasné tabulky a některé složitější operace,
• SQLite má k dispozici nástroje jako SQLite Control Center, či SQLite Web Admin.

Je zde ovšem i pár nevýhod, nelze například použít FULLTEXT klíč, je nutné používat SELECT LIKE ‘%slovo%’, a kromě verze 3.0 (kterou ale zase neumí PHP 5.0.2) zde není nativní podpora UTF-8 (což ostatně neumí ani MySQL 4.0, umí to až 4.1).

Každopádně, podpora pro triggery a views a velikost jen 200KB SQLite je dobrým důvodem, abych SQLite začal používat místo MySQL pro své projekty.

SQLite je prostě fantastická a efektivní “příruční databáze”, navíc pro SELECT příkazy má být rychlejší než MySQL.

Webdesignérská komunita se asi shodne na tom, že nejrychlejší implementace PHP pro Apache, z možností CGI, FastCGI a modulu, by měl být právě modul, protože PHP modul pro Apache je psán pro nativní API Apache 2.0 serveru. Odtud tedy ona rychlost…

CGI naopak v teorii znamená, že CGI skript musí při každém použití PHP vyhledat a parserovat php.ini, spustit php-cgi.exe a natahovat spousty dll knihoven (extensions). To je pomalé, nicméně, vzhledem k tomu, že jsou stejně všechny dll knihovny v RAM paměti, a vzhledem k výkonu testovacího stroje (3.2GHz Pentium-4/HT procesor, 1GB RAM), nebude to zpoždění až tak zásadní.

FastCGI ovšem CGI zlepšuje v tom, že při startu Apache serveru spustí definovaný počet php-cgi.exe procesů v paměti a nechá je běžet po celou dobu, a při požadavku na PHP interpret jim tento dotaz předá ke zpracování.

Tolik tedy teorie. Rozhodl jsem se v praxi otestovat, jak je Apache/PHP kombo rychlé v reálném provozu v režimech CGI, FastCGI a modul.

Testoval jsem funkci, která 1000x za sebou provede vytvoření dlouhého řetezce znaků. Práce s textem je základem PHP.

O eclipse.org, open-source projektu v čele s IBM (podílí se na něm ale i Borland, SUSE, Red Hat, a mnozí další), každý již asi někdy slyšel. Eclipse.org je naprosto dokonalé vývojové prostředí, framework, multiplatformní, a to nejen pro Javu. Za pomocí pluginů je Eclipse možno rozšířit i o podporu například PHP, na což se zaměřuje projekt PHPeclipse.de.

Nutno říci, že Eclipse je skutečně dokonalé IDE. S editací PHP / CSS / SQL / XHTML zdrojového textu v editoru se to nedá srovnávat. Můžete používat PHP debugger, code browser Vám po stisku Ctrl+Space nabídne nejen vestavěné funkce PHP, ale i veškeré funkce, které si Vy deklarujete v include / require souborech, a jejich popis z PHPDoc kompatibilních komentářů (!), nabízí "Resource" a "Debug" perspektivu, real-time prohlížení PHP výstupu ve vestavěném browseru, real-time PHP parser, skvělou správu projektu, integrovanou spolupráci s CVS, včetně podpory pro ssh, přímý import projektu z CVS, podporu a code browser pro nejen PHP, ale i CSS (včetně CSS 2.0), XHTML, a SQL, a mraky dalších funkcí.

PHPEclipse je prostě splněný sen programátora / webdesignéra.

Instalace PHPeclipse a konfigurace debuggeru u celého tohoto komplexu je poněkud náročnější, ale vyplatí se.

Nejlepší na tom je, že tento skvělý projekt je k dispozici jako open-source. Projekt, se kterým se například Dreamweaver MX 2004, či FrontPage 2002 nemůže vůbec měřit. Nikdy. Tolik funkcí, skvěle podaných, prostě jiné IDE / Framework nenabídne.

Včera jsem psal o tom, že skripty psané pro MySQL 4.0 (mysql PHP rozšíření) nejsou kompatibilní s MySQL 4.1 a vyšší (mysqli PHP rozšíření). Nicméně, úprava aktuálních PHP skriptů tak, aby byly funkční s libovolnou verzí MySQL a PHP, je vcelku triviální.

Upravil jsem pro použití MySQL 4.1.6-gamma i manuály pro kompilaci a instalaci Apache, MySQL a PHP:

• Instalace Apache 2.0.52, MySQL 4.6.1-gamma a PHP 5.0.2 na Windows,
• Kompilace Apache 2.0.52, MySQL 4.6.1-gamma a PHP 5.0.2 na Linuxu,
• Compile from source Apache 2.0.52, MySQL 4.6.1-gamma and PHP 5.0.2 on Linux.

Představte si, že v roce 2004 zhruba 95% hostingů na celém světě používá MySQL 4.0.x, nebo nižší (z těch, co MySQL podporují). V PHP se k MySQL 4.0 přistupuje například takto (pro získání veškerých položek článku číslo 1):

// MySQL 4.0.x a nizsi
$resource = mysql_connect('localhost','root','heslo');
mysql_select_db('blogcms',$resource);
$query = mysql_query(
  'select * from items where id=1',
  $resource);
if ($row = mysql_fetch_object($query)) {
  // zpracovani vysledku
}

Jednoduché a funkční. Nicméně, pak si nainstalujete PHP 5 a MySQL 4.1.6-gamma, která je oficiálně doporučená pro veškerý nový vývoj, a veškeré Vaše současné skripty přestanou fungovat, přestože používáte jak mysql (pro vezi 4.0 a nižší) PHP extension, tak mysqli (pro vezi 4.1.2 a vyšší) PHP extensions. Prostě Vaše skripty musíte přepsat na mysqli, zpětná kompatibilita s mysql neexistuje, přestože by měla (dle dokumentace) fungovat.

MySQL ve verzi 4.1.2 a vyšší změnila svůj interní komunikační protokol. Podporuje také pár funkcí navíc, zejména nativně znakové sady jako je utf-8 a unicode, a umožňuje nativní české řazení podle utf-8. To je sám o sobě dost dobrý důvod proč na MySQL 4.1 přejít.

Jedním ze základních nových prvků Windows Longhorn, které uvidíme někdy za 3 až 4 roky, má být integrované prohledávání počítače.

Nicméně, firmy specializující se na hledání, a flexibilnější než Microsoft, jako je Copernic, Hotbot, Google, či X1 nabízejí tyto nástroje, a to ve většině případů zdarma, již dnes.

Copernic Desktop Search

V posledních pár dnech psal téměř každý o Google Desktop Search, a přitom všichni zapomínali, že v této oblasti již dlouho existuje konkurence. Viz například recenze pěti Desktop Search produktů na zdnet.co.uk.

Vyzkoušel jsem jak Google Desktop Search, tak Copernic Desktop Search, tedy dva nejlepší freeeware produkty, a Copernic Desktop Search je minimálně o třídu lepší než Google.

Google má hodně co dohánět… Nejenže má Google Destop Search problémy s češtinou, ale ovládá se, bohužel,  přes webové rozhraní. Copernic Desktop Search UI je klasická exe aplikace, která má řádově více funkčnosti, vypadá lépe, prohledává více souborů, má také náhledy souborů Word, Excel, HTML, PDF, a pěkné vychytávky, jako je například inkrementální hledání při napsání jediného písmene a jeho obnova při pokračování psaní (prostě nemusíte mačkat klávesu Enter, jak píšete, tak se hned prohledává), je tu i automatické zobrazení náhledu prvního výsledku, okamžitá dostupnost Copernic Desktop Hledání po stisku klávesy Win+S, a řadu dalších věcí.

Předmluva Radka Hulána k článku: Ivana Bednářová je velice schopná mladá grafička, která na tomto webu publikuje svůj seriál o použití Adobe Photoshopu pro praxi webdesignu. Ivana má rovněž svůj vlastní web na adrese art-pgn.info.

A protože WELL.DONE se webdesignem zaobírá, a grafika je jeho nedílnou součástí, tvořící první dojem z webu, mám radost, že se Ivana rozhodla své články publikovat právě zde.

V tomto seriálu si ukážeme, jak za pomoci standardních nástrojů Photoshopu vytvořit celý design jednoduché www prezentace, v tomto případě jednoho hotelového zařízení – Hotel Horník a procvičíme si první jednoduché efekty Photoshopu. Nejdříve se podívejme na to, jak bude prezentace vypadat ve finále (obr. 1).

Zvětšit obr. 1

Trochu jsem zkoumal SEO URL, tedy URL pěkná pro člověka i pro vyhledávače.

V současnosti je moderní používat URL typu http://domena.com/clanek/nazev-clanku. Tato SEO URL mají smysl jak pro vyhledávače, tak pro člověka, a mnohem lépe se pamatují než index.php?id=a12d45eef789b.

Jsou zde ale jisté nevýhody:

• Některé browsery, jmenovitě MSIE, načítají při shlédnutí článku CSS znovu, nedrží je v cache, přestože již mají v cache CSS z domény, pokud je URL /clanek/nazev-clanku zpracováváno pomocí FilesMatch, tedy:
  <FilesMatch "^clanek$">
ForceType application/x-httpd-php
</FilesMatch>
• FilesMatch se nedá použít na Microsoftím IIS, umí jej jenom Apache, čímž se omezuje portabilita zdrojového kódu projektu, u open-source projektů je to poměrně závažná věc,
• Protože http://domena.com/clanek/nazev-clanku a http://domena.com/ jsou pro search-engines různé, nesčítá se jejich page-rank, pokud někdo odkazuje na článek, neposiluje tím přímo page-rank domény, a naopak.

Řešením je začít používat SEO URL typu:

http://domena.com/?clanek=nazev-clanku

Výhody?

• Není nutná podpora pro .htaccess a mod_rewrite.
• Není nutná podpora FilesMatch, SEO URL budou tedy fungovat i na IIS.
• CSS nebude žádným browserem znovu načítáno.
• Pro vyhledávače by toto řešení mělo být ekvivalentní s FilesMatch řešením.

Implementuji tyto URL jako alternativní do BLOG:CMS…