Zápisky.info

Programuteje–li v PHP5 řádně objektově, potřebujete přehledně uspořádat zdrojové kódy. Dobrým zvykem je každou třídu umístit do shodně pojmenovaného souboru. Pak se ale uvrhnete do nutnost vyjmenovávat pro každý skript dlouhou sadu volání require_once() a to ve správném pořadí.

Ne! Nemusíte! Existuje možnost naprogramovat funkci __autoload() definující rutinu, jak načítat soubory takto uložených tříd. A volána je pouze pro třídy, které potřebujete a v pořadí, v jakém jsou třeba. Takto se pak načítají i třídy předků (definované klíčovým slovem extends), implementované rozhraní, … Jedinou nefunkčnost jsem objevil, objeví–li se název třídy ve volání $var instanceof ClassName, ale to musím ještě pořádně otestovat.

function __autoload($className) {
  require_once('/WEB-INF/classes/'.$className.'.php');
}

… v striktních objektově–orientovaných jazycích jako Java příjemný pocit jistoty, že vámi napsaný kód funguje dle očekávání. Za to v netypových jazycích jako PHP holá nutnost, která potvrdí, že kód je funkční a správně napsaný. Není nic horšího, než překlepy v názvech tříd/metod/promněnných, zavržené nebo již nefunkční syntaktické rysy jazyka, které nevědomky použijete, chybně pochopený kontrakt metody a další maličkosti, které se těžko odhalí, když vás celou dobu nehlídá inteligentní IDE!

Proces nepřetržité integrace, který se opírá zejména o jednotkové testy, dává možnost neustále kontroly nad funkčním kódem. Jestliže pracujete v PHP, dá sice více práce sestavit testovací prostředí, ale výsledek poznáte, když odchytíte prvních pár „záludných“ chyb. Pro tento jazyk byl implementován balík PHPUnit, který dokáže velmi striktně kontrolovat váš kód a máte k dispozici veškeré vymoženosti z (dejme tomu) JUnitu.

Testy se píšou stejně jednoduše:

<?php
  /* Testovana metoda */
  function neco() {
    return 'neco';
  }

  class MujTest extends PHPUnit_Framework_TestCase {
    protected function setUp() {
      // nejaka nastaveni
    }

    public function testNeco() {
      // testovani metody neco()
      $this->assertEquals(neco(), 'neco', 'Nebylo vraceno neco');
    }
  }
?>

Další kapitolou je řešení problémů, jak testovat systém na selhání, nedostupnost zdrojů a jiné podobné výjimečné stavy. To pak přijde na řadu implementace „mock“ objektů, ale s tím vším se dá vypořádat a ve výsledku máte na očích jednoznačný ukazatel, že kód funguje či ne a nemusíte neustále vše testovat v prohlížeči, jak je mnoho PHP vývojářů zvyklých a následně řešit, jestli je chyba v prohlížeči, ve čtení dat z formuláře nebo logice aplikace. Psát testy se vyplatí!

Vysvětlovat, co je podstatou návrhového vzoru MVC, by asi pro zkušené tvůrce webových aplikací bylo nošením dříví do lesa. Stručně řečeno jde o způsob, jak oddělit logiku práce s daty od jejich reprezentace. Takové rozhraní poskytuje snad každá platforma pro vývoj webových aplikací: Java jako JSP a knihovny tagů, .NET balíček Web.Forms, díky kterému lze ve vývojovém prostředí „naklikat“ ve Visual Studiu stejně jako by šlo o desktopovou aplikaci. V PHP je situace jiná. Žádné oficiální MVC řešení neexistuje. Proprietální si však může každý napsat sám. Já zde popíšu to, které jsem využil například na aplikaci raillog.

Jak by se Vám líbilo, kdyby soubor index.php Vaší aplikace vypadal takto?

<?php
  // načtení knihoven aplikace
  require('_application.php');
  // spuštění
  SampleApplication::run();
?>

Vím, je to trochu strohé a může to znamenat problémy v dalším vývoji, ale mně to vyhovuje ... a nevypadá to úžasně?

Pokračování »

Občas je dobré se spolehnout na produkty jiných osob. Pokud chcete začít psát eZine, proč programovat vlastní CMS systém, když jeden velmi kvalitní existuje (BLOG:CMS). Rovněž nemá cenu si kupovat nový server, instalovat a konfigurovat veškerý software na něm a pak draze platit za umístění tohoto počítače v nějakém „server house“, když lze využít služeb nějakého placeného hostingu (v mém případě banan.cz). Zlé ovšem je, když i přes využití produktů, které zaručují bezproblémové používání, problémy nastanou ...

Podobné problémy mě trápily již před časem. Na hostingu přepnuli nastavení databáze MySQL (zřejmě vypnuli defaultní kódování UTF-8) a tak z ničeho nic zmizely z mých stránek české znaky a byly nahrazeny "?" znaky otazníku. Tehdy jsme hosting urgoval tak dlouho, dokud vše nenapravil – jak se to podpoře povedlo, to doteď nevím a je to možná škoda. Minulý týden jsem instaloval poslední verzi aplikace BLOG:CMS 4.0.0j na jednu poddoménu a narazil na stejné problémy. Opět jsem chybu oznámil na podporu.

Rada č. 1: Musíte mít v zdrojovém kódu nastaveno kódování data přijímaných z databáze:

sql_query("SET NAMES 'utf8'");
sql_query("SET CHARACTER SET 'utf8'");

Myslíte si, že něco takového Radek Hulán při vývoji aplikace opomněl? Nikoliv!

Rada č. 2: Databáze má nastaveno kódování na cp1250! BLOG:CMS neobsahuje v instalační dávce nastavení kódování jednotlivých tabulek a správné collation. To je jeden potenciální problém. Bohužel, při vytváření databáze přes administrační rozhraní hostingu si nezvolíte, jaké kódování bude ona databáze mít a změna přes aplikaci phpMyAdmin není úplně triviální.

Když jsem vše, co podpora hostingu radila, udělal, začala se diakritika zobrazovat správně — až na záludné písmeno "č" a "Č". Jsou to jen dvě písmena, ale nemůžeme požadovat poloviční řešení. Korespondence s podporou pokračovala. Poslal jsem jim (po vyzvání) i přihlašovací údaje do CMS aplikace, aby vše mohli ozkoušet. V neděli dokonce přišel e-mail ... zdá se, že již čeština funguje ...

A mně se zdá, že ne! Co teď? Nesetkal se někdo z vás s podobným problémem? Prosím o jakoukoliv radu. Děkuji.

Dagi se dal na zaříkávání PHP. Položil pár jednoduchých, ale zásadních otázek, bez jejichž uspokojivého zodpovězení nelze považovat toto vývojové prostředí za dostatečné pro vývoj pořádných webových aplikací a služeb. Jak jsem se díval do komentářů, tak opět převládl hlas lidí, pro které je jediným argumentem „flame“. Ale najdete i kvalitní podněty. Co si o PHP myslím já?

Posledního půl roku se věnuji PHP5, protože jeho podpora objektově–orientovaného programování se alespoň trochu přiblížila realitě. I přesto jde o slátaninu tuny funkcí, které dělají vše možné. Nejvíce mi vadí ošetřování chyb. Polovina funkcí vrací třeba boolean podle toho, jak operace dopadla, jiné vyhazují varování či chybu, kterou neodchytíte a ty slušnější vyhazují výjimky. Co naplat, člověk pak raději nechá aplikaci zhroutit, než by se do tohoto trojího ošetřování chybových stavů zahrabal.

V oblasti MVC frameworků se musíte spolehnout na vlastní schopnosti nebo různé proprietální řešení. Jako jedno z nejzajímavější považuji PRADO, které je založeno na principu událostmi řízených komponent.

Instalační skripty nebo integrace různých hotových produktů, to vše si musí autor napsat sám.

Co se publikační nástrojů týká, je v PHP poskytována široká nabídka &ndash jména jako Wordpress či BLOG:CMS jsou u nás dostatečně známé. I přesto to, že tyto systémy obsahují spoustu pokročilých rysů, ne každému úplně padnou.

Pokud náhodou uvažujete o práci s RDF, pak moc na výběr nemáte. Knihovna RAP je stále postavena na PHP4, chyby ošetřuje přes neodchytitelné chyby či varování, její řešení práce s kódováním je taková, že české znaky se vám budou zapisovat v notaci Unicode: \0xxxx.

Celkově PHP postrádá mnoho z moderních nástrojů, využívání této platformy mi připadá jako nekonečné znovu—objevování již objeveného. Jediná výhoda je v tom, že stejně jako jazyk Python, lze v něm v okamžiku provést prototypovou implementaci libovolné webové aplikace. Pokud ale chcete vytvořit něco většího, doporučuji se obrnit hodně velkou trpělivostí.

Někde jsem četl, že Zend Development Environment je to nejlepší vývojové prostředí pro psaní a ladění aplikací programovaných pomocí PHP5. Nedalo mi to, abych si nestáhl trial verzi tohoto komerčního produktu a alespoň krátce jej neotestoval.

Musím říct, že implementace napovídání je napsána velmi dobře. Občas jsem si připadal jako bych psal nějakou aplikaci pod Eclipse. V malém okně Inspectors vidíte strukturu aktuálního souboru – deklarované konstanty, metody a objekty – pokud objekty dědí z jiných tříd nebo implementují rozhraní, vidíte i strukturu těchto tříd/rozhraní. Součástí studia je i klasická práce s projekty.

Pokud píšete objekty a dokumentujete je pomocí komentářů phpdoc (obdoba javadoc), pak vám prostředí samo nabízí jednotlivé tagy. V aplikaci je integrován i nástroj phpDocumentator, takže si můžete zmíněnou dokumentaci ihned vygenerovat a nemusíte se zdržovat s instalací tohoto nástroje.

Co mi trochu vadilo, byla pomalá odezva nástroje na mé příkazy. Nevím proč, ale neustále nestíhal zpracovávat instrukce. Testoval jsem ho na téměř novém notebooku s procesorem Pentium D 1,7 GHz, 512 MB RAM a 128 MB grafickou kartou (není integrovaná) ...

Nástroje pro ladění a debuggování jsem netestoval. Popravdě, ještě jsem si nezvykl je používat. Při psaní PHP aplikací si vystačím s funkcemi echo() a print_r().

Celkově se jedná o povedený produkt a kdyby nebyl komerční, hned bych jím nahradil editor jEdit, který nějaký ten měsíc používám místo PSPadu, který v každém druhém releasu zapomene poskytnout volbu zalamování řádků a neustále mi otevírané soubory překódovává na windows-1250. Kontextová nápověda a generátor dokumentace jsou více než lákavé rysy.

Aplikace RailLog je mým věčným zdrojem inspirace pro další studium nových rysů PHP5. Po přečtení jedné knihy o refaktoringu (o té někdy příště) a opětovném prohlédnutí kódu mi silně začalo vadit, že všechna data mám „natvrdo“ deklarovaná v _model.php a rozhodl se je uložit do nějaké formátu, který je jednodušší pro editaci uživatelem ... zvolil jsem XML.

Formát XML jsem zvolil ze dvou důvodů. a) chtěl jsem si konečně vyzkoušet napsat vlastní DTD a b) chtěl se naučit pracovat s novým PHP modulem SimpleXML. Celé mi to připomíná řešení, které jsem použil, když jsem zkoušel napsat jednoduchý „tree view“ pro Eclipse zobrazující určitý XML soubor. Utilita načte XML ze souboru (simplexml_load_file( string $filename )) nebo z in–line řetězce (simplexml_load_string( string $xmlsource )) a vytvoří jednoudchou strukturu z objektů a polí, kterou lze jednoduše procházet pomocí kostrukce foreach.

Uvažujme následující XML strukturu (z navrhovaného XML formátu aplikace RailLog):

<?xml version="1.0" encoding="UTF-8"?>
<raillog>
  <stations>
    <station id="ceska-trebova" name="Česká Třebová"/>
    <station id="hranice-na-morave" name="Hranice na Moravě"/>
    <station id="olomouc-hln" name="Olomouc hl.n."/>
    <station id="praha-hln" name="Praha hl.n."/>
    <station id="svitavy" name="Svitavy"/>
  </stations>
</raillog>

Pro načtení této struktury a vytvoření objektů Station stačí pár řádek kódu:

<?php

  $stations = array();

  $data = simplexml_load_file('raillog.xml');

  foreach ($data->stations[0]->station as $station) {
    $stations[] = new Station(
      (string)$station['id'], (string)$station['name']
    );
  }

?>

Zde vidíte, že jednotlivé objekty mají jako své vlastnosti názvy vnořených elementů, které obsahují pole se svými vnořenými elementy, atd. každý element zárověn obsahuje asociativní pole s obsahem svých atributů, kde jejich indexem je název elementu. Samozřejmě, pokud 100% znáte strukturu cílového souboru a chcete vypsat, dejme tomu, název prvního nádraží, můžete k vlastnostem přistupovat přímo:

  echo((string)$xml->stations->station[0]->name);

Umíte–li XPath, není nic jednoduššího, než prohledávat XML strom pomocí něj. Takto lze vypsat všechny vlaky ze souboru (v naše XML se element jmenuje train):

foreach ($xml->xpath('//train') as $train) {
  echo((string)$train['name']);
}

Stejný způsobem lze k vlastnostem přistupovat a měnit jejich obsah. Následně můžete upravenou XML strukturu zpětně získat v XML syntaxi – $xml->asXml().

A to je vše. Pokud hledáte nějaké detaily o tomto modulu, doporučuju dokumentaci PHP.

RAP ve verzi 0.9.1 poskytuje již v základní instalaci slovníky zdrojů 8 nejpoužívanějších RDF schémat - RDF, RDF Schema, OWL, Dublin Core, FOAF, RSS, Atom a vCard. To je velmi dobrá zpráva pro všechny, protože se tím velice zpřehlední kód a zjednoduší práce. Má to však své velké ale!

Způsob, jakým byly tyto slovníky napsány a jakým se používají, se liší skoro verze od verze. Je pravda, že RAP je zatím (skoro) plně zpětně kompatibilní, takže aplikace, která byla vyvíjena na verzi 0.1 by měla jet, i kdyby jste jí „podstrčili“ poslední build z CVS, ale jsou zde jistá omezení ... která mě trošku potrápila a vadí mi.

Ani taková banalita, jako „instalace“ slovníků, nezůstala nedotčena. Původně se načítání nastavovalo přímo v jádru RdfApi.php, kde stačilo příslušné volání funkce require( string $path ) (za/od)komentovat. Ve verzi 0.8 byla zavedena konstanta, přes kterou šlo celý balíček slovníků načíst:

require( RDFAPI_INCLUDE_DIR . PACKAGE_VOCABULARY );

Verze 0.9 šla ještě dál a nyní si můžete načíst v rámci konkrétního PHP soubor přesně ty knihovny, které potřebujete a navíc máte výběr mezi „statement-centric“ a „resource-centric“ modelem.

Také použití se změnilo. Původně stačilo k získání určité vlastnosti/třídy vědět, jak se jmenuje její konstanta a tu zapsat do zdrojového kódu. Takže třeba vlastnost rdf:type byla definována jako $RDF_type. Nově jsou všechny vlastnosti sdruženy do třídy, kde jsou vytvářeny „statickými“ metodami - ty uvozovky jsou zde proto, že RAP je stále napsáno v PHP4 a to statické metody nepodporuje. K získání výše uvedené vlastnosti nyní musíme volat metodu příslušné třídy:

RDF::TYPE();
// nebo pro resource–centric model
RDF_RES::TYPE();

Poznamenejme, že jmenné prostory jednotlivých slovníků nejsou uchovávány uvnitř tříd, ale v mamutím souboru, který definuje všechny konstanty RAP. Možná je to přehnané, populistické, ale proč by nešlo napsat ty slovníky nějak takhle:

class RDF {
  // definice jmenného prostoru
  const NS = ' ... URI jmenného prostoru RDF ... ';
  // zakážeme vytváření instancí této třídy
  private function __construct() {}
  // funkce vytvářející vlastnost "rdf:type"
  public static function TYPE() {
    return new Resource( self::NS . 'type' );
  }
  // Stejně tak i pro ostatní třídy
}

Bylo by to krásné, ale nemá cenu přepisovat balík slovníku do PHP5, když nebude ve stejném duchu napsaný celý model knihovny RAP, parsery, ošetření chybových stavů pomocí výjimek. No, jak řekl jeden z autorů této knihovny, bude to chtít prodiskutovat a hodně času na promyšlenou. Jediné, co mě může těšit, je, že RAP je plně funkční i pod PHP5.

O tom, že MySQL není vše a existují i lepší řešení pro vaše aplikace psané v PHP5, nás přesvědčil již Radek Hulán. Pokud si pamatuju, tak následně implementoval skvělou databázi SQLite do jeho redakčního systému BLOG:CMS. Já v současné době pracuju na verzi beta 2 aplikace Advanced FOAF Explorer. Dal jsem si závazek, že to dopíšu do začátku prvního semestru na ekonomce a snad se to i povede. Jelikož jsem za poslední rok dost zhýčkaný objektově orientovaným programováním, píšu AFE právě v PHP5, protože jeho podpora objektového návrhu je, na rozdíl od verze 4, dostačující. Jelikož jsem poslední dobou trošku „vysazený“ na MySQL, chtěl jsem použít něco jiného ...

Výhodou databáze SQLite je, že je integrována v jádře PHP5. Tím pádem nejste závislí na nastavení hostingu. Stačí mít právo zápisu do nějakého adresáře (chmod 777). Stejně tak se mi líbí, že vyjma funkcí pro práci s touto databází je implementována i třída SQLiteDatabase, která všechny funkce sdružuje a vytváří tak jednoduché objektové rozhraní pro práci. Jako příruční nápověda se nejlépe hodí článek SQLite Introduction (zend.com), který na jednoduchých příkladech dokumentuje vše, co lze v praxi při práci využít. Tím pádem považujme komponentu HistoryStorage pro AFE za hotovou.

Jen pro doplnění. Pokud hledáte nějaký freehosting, který PHP5 (a tedy i SQLite) podporuje, zkuste php5.cz.

Poslední dobou mě pár entit na ShadowNetu otravuje s požadavky na změny v systému. Jelikož nemám čas se prodírat tou nedokumentovanou změtí kódů a kolegové mi nevěří, že to není tak jednoduché se v tom vyznat, vystavil jsem zdrojové kódy SN 2.12.50 na stránkách, aby si je mohl stáhnout každý a libovolně modifikovat ... pokud má někdo chuť, může si nainstalovat vlastní diskusní server.