vojtěch vondra » PHP

Nette Templates pro Zend

Vojtěch Vondra — Sun, 13 Feb 2011 14:13:31 +0000

Netťácké šablony jsem si hned oblíbil a používal je nejen s kompletním frameworkem. Zend Framework umožňuje vcelku nahradit výchozí “šablonovací” systém jiným a vzhledem k existujícím projektům, které spravuji a kde by se mi Nette šablony hodily, jsem vytvořil vcelku jednoduchou přemosťující třídu, která umožňuje použít Nette Templates v Zend Frameworku.

Stažení

Třídy včetně příkladu implementace lze najít v repozitáři na Githubu.

Použití

Do aplikace si stačí nahrát Nette Framework (celý) a dvě třídy (jedna pro samotnou implementaci šablon, druhá pro doplnění maker, které nebudou v původní formě fungovat). Pak už je jen potřeba nahradit původní Zend_View šablonami z Nette.

V repozitáři to nemám úplně pěkně uděláne. Narozdíl od Nette, kde bych na to použil společný presenter, je v Zendu lepší vyčlenit inicializaci do Controller pluginu. Každopádně až na umístění pár drobností bude implementace vypadat stejně jako příklad v repozitáři.

Layouty

Systém nebude fungovat s Layoutovými třídami ze ZF. Je potřeba je vypnout a layout si vytvořit sami přes bloky a makro {extends}. V šabloně pohledu bude tedy např.:

{extends '../../../layouts/scripts/layout.phtml'}
{block content}
obsah ....

a layout budu mít definovaný takto:


	
		
			Nette View in Zend Test
		
	
	
		{include #content}

Funkčnost maker

V současné implementaci mám pouze základní podporu pro makro {link}, zápis odkazu se ale spíš blíží použití klasického URL helperu ze Zend_View. Chtělo by to ještě dodělat podporu pro {ifCurrent}

{control} přirozeně nefunguje.

Nezkušený programátor aneb jak zabít článek

Vojtěch Vondra — Thu, 16 Sep 2010 16:54:44 +0000

Michal Maňák si na svém blogu postěžoval, v jakém stavu dostal do rukou projekt postavený v PHP na Nette frameworku. Čekal jsem slibný článek o best-practices, který by mohl (zvlášť při publikaci na Weblogy.cz) přimět pár programátoru (co třeba s Nette nebo MVC začínají), aby přehodnotili některé své přístupy a podívali se na alternativní varianty řešení problémů.

Autor se zabývá margináliemi, u kterých se sám s potýká s menšími či většími problémy. Když se pustím do někoho jiného, dám si sakra pozor, abych sám neměl někde nějakou hloupost, čtenáři si při hodnocení kritického článku málokdy berou servítky a komentáře pod článkem to reflektují poměrně dobře.

Vytváříme model (pořádně)

Nejde mi o to celý článek rozebrat, spíš se ale zaměřit na drobnosti, které se v něm objevily a které dobrotu rozhodně v žádné aplikaci nenadělají. Přejděme tedy k ukázce č. 1:

class ObjektModel extends BaseModel {
    public function getData(){
        return dibi::query('SELECT * FROM tabulka')->fetchALL();
    }
}

BaseModel většina Nettistů používá jako abstraktní třídu, která obstarává základní CRUD operace přes dibi nebo jiný databázový layer. Potomci jen nadefinují klíč a tabulku a dědí většinu metod. V tom je tedy první připomínka: proč ji třída ObjektModel definuje znovu? Nic nad rámec toho, co pravděpodobně bude v BaseModelu tam rozhodně nebude. Za druhé se autor zbytečně omezuje použitím fetchAll(), v takto jednoduchém rozvržení modelů je mnohem výhodnější nechat fetch*() metody až na presenter a vytáhnout si tak data, které potřebuji.

Není na ní nic špatného, ale změnil bych použití databázové vrstvy dibi na přehlednější zápis dibi::select(‘*’)->from(‘tabulka’)->fetchALL();. Dotaz je podle mě přehlednější a je také jisté, že se na nic při skládání dotazu nezapomene.

Tak tohle je už jen taková obecná polemika, sama na závadu není, názor nikomu brát nemohu, je ale škoda, že přehlcuje článek úplně o nečem jiném. Spousta programátorů zas DibiFluent přeceňuje a často se do ní zamotají tak, že nevidí, že dibi::query() by bylo mnohokrát snadnější.

Trochu lepší řešení by mohlo být třeba toto, přestože je poměrně schematické, je funkční a čistší. V PHP 5.3 by šlo uvažovat nad tím využít Late Static Binding a $table mít staticky nadefinovaný, stejně tak jako celý BaseModel.

abstract class BaseModel extends Object {
     protected $table;
 
    /**
    * Vytáhne data z tabulky
    * @return DibiResult
    */
    public function getData()
    {
        return dibi::query('SELECT * FROM %sql', $this->table);
    }
}
 
class ObjektModel extends BaseModel {
    public function __construct()
    {
        $this->table = 'tabulka';
    }
}
 
// Nakonec si vytáhneme data jak jen potřebujeme.
$m = new ObjektModel;
$data = $m->getData()->fetchPairs('id', 'name');

Nebastlíme divoké funkce

Podívejme se třeba na následující volání, co si myslíte, že vrací metoda zkontrolujHeslo()? Ja bych tipnul true/false.

$uzivatel = VlastníModel::zkontrolujHeslo($data);

Metoda by měla vrátit hodnotu, která odpovídá jejímu pojmenování
Oproti řešení minulého programátora už tak striktně netrvá na validaci vstupních dat, které vstupují do databáze.

Navíc tam u každé ukázky proběhnou takové nepodložené zvolání:

Mně se takový zápis dotazů rozhodně nelíbí, je to zbytečně složité a jde to mnohem jednodušeji. Chyba je samozřejmě už v presenteru, kde se data už měla odeslat jako array() a v dotazu pouze zapsat dotaz. Model byl vypadal takto:

Proč? Co nám brání mít funkci s dvěma parametrama? Uvítal bych třeba jeden jediný důvod, třeba:
Aplikaci chceme postavit maximálně modulárně. Vzhledem k tomu, že může existovat více možný způsobů ověření přihlašovacích údajů, interface, které definuje jak se má obstarat kontrola přihlášení (např. metodou zkontrolujUdaje()), necháme přijmout pole a ne pevně danou sadu argumentů, které mohou platit jen pro nekteré případy.

Nebo třeba o pár řádku výše psané:

To, že se pak zpracovával formulář bez zachytávání výjimek try {} catch {}, ale pouze s kombinací if(funkce()){}, někdy i bez ní, nepřijde nutné ani komentovat a taky mi to nepřipadá zrovna nejvhodnější a bezpečné pro zpracování dat.

WTF? Od kdy je zachytávání výjimek výše než podmínkový blok? Každé má své specifické použití a podobné zvolání je jen nefunkční generalizace.

Konec dobrý, všechno dobré

Na článku je několik pozitivních věcí. Připomenout, že se formulář dá plnit vlastní metodou a získat hodnoty z něj taktéž, může někomu ušetřit minuty hledáním dokumentace třídy Nette\Form. Ukázat lidem, že existuje poměrně příjemná třída DibiFluent, může leckomu rozšířit obzory. Podnítit ostatní, aby nenechali podobné kraviny ležet ladem, snad zabrání, aby se někdo na podobných článcích učil programovat.

Kontrola syntaxe PHP skriptů

Vojtěch Vondra — Thu, 09 Sep 2010 07:45:09 +0000

Na Albeři jsem před týdnem slyšel dobrou historku o tom, jak se muselo počítat s chybama v minulosti. Matfyzák si napsal program, poctivě naděrkoval a strčil do stroje. Po nějaké době chroustání doběhl o dvě patra výše pro výpis chyb a začal na novo. Pořádně si rozmyslel jestli for začne od nuly nebo od jedničky.

Sám procedurální části kódu v PHP často píšu tak, že si dám dohromady celý kód, a pokud nemám k dispozici IDE, které mi rovnou syntax errory zvýrazní, skript nechám běžet a zjistim, jestli v něm nejsou chyby. Samozřejmě má ten přístup své nevýhody: často mi unikne chybějící čárka či středník v knihovně, kterou nespouštím přímo, nebo prostě mi jeden nebo víc souborů uteče.

Standarní PHP CLI binárka má šikovný parametr -l (lint), který bere jako argument PHP soubor a vypíše, jestli v něm nění nějaký Parser error. Pro pohodlnost lze použít tento příkaz, který projede rekurzivně všechny soubory v současném adresáři a zkontroluje u nich syntaxi:

find -type f -name '*.php' -exec php -l {} \; | grep "Parse error"

Výsledkem pak může být třeba:

vojta@vvondra-laptop:~/public_html$ sh syntax.sh
PHP Parse error:  syntax error, unexpected T_STRING in ./app/extensions.php on line 10
PHP Parse error:  syntax error, unexpected T_REQUIRE in ./app/bootstrap.php on line 14

Pomocník automatický

Ještě šikovnější věc jsem ale viděl v našem repozitáři pro phpBB na GitHubu, pre-commit hook, který zabrání commitu, pokud je v nějakém souboru syntax error.

To už je jen na vás, jak zpracujete.

Nezobrazují se JPEGy v IE a Chromu

Vojtěch Vondra — Thu, 12 Aug 2010 09:35:05 +0000

Na současném projektu jsme dokončili rozhraní pro správu bannerů a klient už nám po několika minutách volal s chybou, že se nahraný obrázek nezobrazí. Podíval jsem se na něj ve Firefoxu a v Opeře a vše v pořádku. Ptám se tedy na prohlížeč a zjištuji, že jde o IE8.

Po chvilce na Google jsem přišel na příčinu, která by mě rozhodně dříve nenapadla. Některé (třeba starší IE s tím nemají problém) verze Internet Exploreru a Chromu (snad i starší Firefox byl postižen) mají problém s renderováním JPEGů uložené s CMYK barvami.

Řešení je snadné, pokud jde o designové prvky na webu, které máte pod palcem, a pokud máte po ruce Photoshop nebo GIMP. U obou shodně přejděte v menu na Obrázek / Image > Režim / Mode a zvolte RGB, GIMP dokonce nic jiného neumí.

Problém je, pokud to uživatelé nahrávají na web. Pak je potřeba obrázek načíst přes GD a znovu uložit. Nejnovější funkce imagecreatefromjpeg() a imagejpeg() to převedou do RGB. GD s CMYK pracovat neumí a nevýhoda tohoto řešení je ztráta kvality při změně barev.

$image = imagecreatefromjpeg('/cesta/k/souboru');
imagejpeg($image, '/cesta/k/souboru');

Detekovat jestli je obrázek RGB nebo CMYK lze snadno s funkcí getimagesize()

$info = getimagesize('/cesta/k/souboru');
if (sizeof[$info['channels']) == 3)
{
    echo 'RGB!';
}
else if (sizeof($info['channels'] == 4))
{
    echo 'CMYK!';
}

IDF2010 – moje postřehy

Vojtěch Vondra — Thu, 08 Apr 2010 13:29:06 +0000

Přestože jsem včera stačil dorazit až na půlku přednášky Davida Grudla o webových aplikací, druhá část programu na mě stihla udělat docela dojem. Jednoznačně jsem byl potešený organizací, snad jedině clip-on mikrofony chyběly a brzdilo to některé přednášky. Skvělá byla i spontaneita přednášejících, např. u Jirky Knesla bylo rozhodně zajímavé koukat i na psání kódu a přednášku to rozhodně nebrzdilo.

Většina prezentací by si zasloužila hodiny dvě. U Davida Grudla by mi přišla přednáška prázdná. Na to, jak vytvořit v Nette autocomplete by se mohl udělat stránkový tutorial. Chtělo by se to spíše zaměřit na konkrétnější a zajímavější věci.

Až na výjimky vypadali přednášející připraveně, někde mohl být projev plynulejší nebo přednáška mohla být lépe strukturovaná. Honza Král povídající o NoSQL by mohl začátek prezentace udělat přehlednější, byl určen lidem, co neznají základní pojmy u databází a právě pro ty to mohlo být špatně srozumitelné.

Je mi dost líto, že jsem nestihl přednášku D. Steigerwalda o objektech v JavaScriptu, ohlasy u oběda byly docela pozitivní. Pro mě nejpřínosnější byly příklady z praxe od Jirky Knesla, zvlášť co se komunikace týče. Zároveň mě přesvědčil, abych důkladněji se věnoval testům u svých aplikací.

Celkově mi příšlo IDF jako výcuc, který mohl mít na třídenní přednáškovou konferenci se skvělým obsahem. Příště by to chtělo stejnou či lepší úroveň přednášejících, delší a hlubší příspěvky, klidně více specializované. Přednášky by měly konceptuálně navazovat, systém “od všecho trochu” mi přijde trochu nešťastný. Vyhozených (studentských) šest stovek to ale nebylo.

Seznam CAPTCHA plug-in pro phpBB

Vojtěch Vondra — Thu, 04 Feb 2010 21:54:23 +0000

S vydáním phpBB 3.0.6 přibyla výrazná nová funkce, možnost vytvořit plug-iny pro alternativní CAPTCHA systémy. Kromě toho Seznam (tim myslím Seznam.cz) vydal už před delší dobou velmi jednoduché API pro čitelnou a použitelnou CAPTCHU. Já se rozhodl ty dvě věci spojit dohromady.

Naštěstí to moc práce není. Rozhraní pro implementaci plug-inu je pouze o využití několika funkcí definovaných v abstraktní třídě captcha_abstract.php a přizpůsobit kód způsobu kontroly zadaného kódu.

Celý zdroj je k dispozici na GitHub a je uveřejněný pod MIT licencí. Dejte si ale pozor na smluvní podmínky od Seznamu, které například omezují použití CAPTCHY pro komerční účely. Na webu API najdete celé znění podmínek. Limity pro využití jsou nastaveny následovně: max. 500 dotazů za 10 sekund, nebo 1 000 dotazů za 60 sekund.

CAPTCHA nabízí i odkaz pro přehraní kódu zvukově, což je příjemné pro handicapované uživatele.

Stáhnout Seznam CAPTCHA plug-in pro phpBB
Diskuze na phpBB.cz

Rozhodně bych uvítal minimálně slovenský překlad, pokud má někdo možnost i jiných, rozhodně dejte vědět.

Why it’s wrong to implement features by popularity

Vojtěch Vondra — Fri, 29 Jan 2010 19:34:54 +0000

Over at the Area51 forums on phpBB.com, where most of the public discussion around phpBB4 development is held, I overheard an argument saying that we should deploy a page where user incentives to new features should be listed and it would be possible to vote on them. While the idea of developing a products accustomed to users using their own opinions is nice, it simply will not work.

There are several issues which I find blocking such a workflow. First it is the participation of the users themselves. Only a handful of users from the whole userbase of phpBB participates in the development discussions and they do not represent a significant part of the community. This is natural, as following the background discussions of every piece of software you use is simply impossible. What more, these users (I often include myself in this description) usually have a deformed view of what the product should look like and lack the necessary distance which could give them a better and more general view of what the product needs. Having a vote on a feature suggestion will certainly not bring a representative result usable to make a decision about implementing a feature.

There have been a few very interesting ideas that came up in the discussion of the new product. One of them was the separation of core features and moving them to a pluggable level. The main positive effect of this measure I see is that the already feature-filled interface can be simplified on each installation giving administrators an option to opt-out from using some of phpBB’s features and not bloating their board with them.

Most of the features that users will suggest and have suggested in similar experiments before were basically adding up of new features that would be useful for only a limited amount of users. Such features and add-ons should be provided in form of modifications, which allow every administrator to customize his board. The phpBB development team on the other hand should provide an intuitive and working modification interface, which would easily allow users to add such modifications.

If I return to the example of the current discussion about phpBB4, in my opinion, the discussion should be led about key structural and feature concepts. Feature themselves should be kept to a minimum. To bring up a topic and proposal that will be implemented, it is necessary to provide a well thought through concept. This means thinking about the target audience, the effect on the board as whole, maintainability and usability. It certainly is not about getting a long list of users to support your idea.

Skript na kontrolu dostupnosti domény

Vojtěch Vondra — Sun, 24 Jan 2010 17:51:09 +0000

Pro potřeby jinde jsem před časem dal dohromady jednoduchý skript na kontrolu dostupnosti domény.

Je to napsané v PHP a obalené v třídě, která se o všechno postará.

V tuto chvíli podporuje tyto TLD: cz, info, com, net, de, eu, biz, name, org, sk

Ukázka použití:

$d = new DomainChecker($domain);
 
if ($d->isAvailable())
{
 echo 'volná';
}
else
{
 echo "registrovaná, informace o majiteli:\n";
 echo $d->getDomainData();
}

Stáhnout

Náhodné řazení v různých databázích

Vojtěch Vondra — Sun, 03 Jan 2010 10:21:45 +0000

Pro jednu modifikaci jsem nedávno řešil jeden z dalších problémů implementace jedné funkce v různých databázových systémech. Šlo o klasický ORDER BY RAND() z MySQL.

Kód jsem tvořil pro phpBB, které podporuje následující: MySQL, PgSQL, MSSQL, Oracle, SQLite, Firebird.


switch ($db->sql_layer)
{
    case 'mssql':
        $random = 'NEWID()';
    break;
    case 'postgres':
    case 'sqlite':
        $random = 'RANDOM()';
    break;
    default:
        $random = 'RAND()';
    break;
}
 
$sql = 'SELECT something FROM some_table ORDER BY ' . $random;
?>

Oracle mi přichystal trochu nepříjemnou záležitost, nutný sub-select:

SELECT COLUMN FROM
( SELECT COLUMN FROM TABLE
ORDER BY dbms_random.VALUE )
WHERE ROWNUM = 1

To jsem ale nezkoumal Firebird. Nejdříve je potřeba definovat vlastní funkci:

DECLARE EXTERNAL FUNCTION rand RETURNS DOUBLE PRECISION BY VALUE ENTRY_POINT 'IB_UDF_rand' MODULE_NAME 'ib_udf';

a poté použít klasický ORDER BY RAND();

Programátorovo čisté svědomí

Vojtěch Vondra — Thu, 20 Aug 2009 19:02:37 +0000

Počítejte s různými prostředími

Nedávno jsem měl v práci možnost opravovat jednoduchý skript (jednoduchá objednávka s odesláním mailu) a pousmál jsem se, co vytvořilo ten humbuk. Stačilo přesunutí na nový server, kde měla direktiva error_reporting v PHP jinou výchozí hodnotu. Téměř celý web se ocitl v jedné chybě jen proto, že byly najednou zobrazeny chyby úrovně E_NOTICE.

Přestože většinou tyto zprávy neovlivní chod aplikaci s omezeným error reportingem, jsou známkou špatného programování, ať už z uspěchanosti, unavenosti nebo pouhé lenosti. Kód by měl být vždycky takový, že se tyto zprávy vypisovat nebudou.

Ukázkový příklad je získání proměnné z globálního pole $_GET nebo $_POST, což je velmi často využíváno při zpracování formulářů (spíše téměř vždy):
$message = $_GET['message'];
Nyní si zapněte výpis E_NOTICE a koukněte co se stane, pokud stránku načtete; PHP vás varuje, že pouíváte nedefinovaný index pole $_GET.

Správný zápis vypadá následovně. V této fázi se rovněž uplatní zkontrolovat datový typ, který očekáváte, hlavně u integerů.
$message = isset($_GET['message']) ? $_GET['message'] : '';

Kromě nedefinovaného indexu pole je druhou nejčastější chybou nedefinovaná proměnná. PHP je v tomto ohledu velmi flexibilní, až mi někdy přijde, že je to příliš. Pokud kontrolujete hodnotu proměnné, ujistěte se, jestli vůbec byla definovaná. Ještě lépe vždy proměnnou sami definujte, kontrola neinicializovaných proměnných může být s zapnutou direktivou register_globals velmi nebezpečná.

Dalším případem může být zapisovatelnost adresáře nebo souboru, se kterými vaše skripty počítájí. Místo toho, abyste byli nemale překvapeni, když skript nenajde to co potřebuje, nejdříve zkontrolujte, zda-li má dostatečná oprávnění. V takovém to výčtu mohu jít mnohem dál, pokud bych shrnul nejčastější prohřešky v tomto ohledu, tak si představím toto:

Počítejte s všemi možnými situacemi, váše aplikace by měla běžet bez chyb nehledě na prostředí (pokud není stanoveno jinak v požadavcích, například přítomnost určitého rozšíření nebo binárky)
Dávejte si pozor s čím pracujete, nepokládejte za samozřejmé, že je proměnná definovaná, ověřte si, že funkce dává výstup jaký očekávejte
Vhodně a včas zachyťte výjimky a zpracujte je

Nenechte vaše skripty, aby se vám vymkly z rukou

Uživatelé na vašem webu mohou být hraví, mohou zkoušet různé parametry (např. pokud máte někde script.php?action=delete), zadávat nesmyslné hodnoty, budou se pokoušet probourat do vaši aplikaci. Nenechte je, a postavte vaši aplikaci tak, aby jste ji ovládali vy a vědeli co dělá. Musíte to ale udělat tak, aby to co nejméně zasáhlo samotného uživatele.

Na formulářích je to vidět ze všeho nejlépe, vždy si ověřte zadávané hodnoty. Využijete regulérní výrazy, kontrolu délky, někdy postačí jen kontrola datového typu. Pokud uživatel něco zadá špatně, buďte vlídní a přesměrujte ho zpátky a naveďte ho na správné řešení.

Pokud je možno více druhů zápisu nějakého pole, zkuste je zpracovat více způsoby a pokud i tehdy nebudou zadaná data dávat smysl, přesměrujte uživatele zpět a mile ho upozorněte.

Opomenutím tohoto bodu se často můžete vystavit nepříjemným věcem jako jsou XSS útoky, z nedávné doby jistě každý ví o co jde. Hlavní pravidlo tedy zní:

Předpokládejte, že uživatel může udělat cokoliv na vašem webu, dovolte mu provést jen to, co by měl!

Nepodceňte bezpečnost

Toto téma jenom zmíním ve zkratce, zaslouží si mnohem více prostoru než zde můžu poskytnout a mnoho lidí už napsalo lepší články, než bych dokázal já.

Při návrhu a psaní aplikace je potřeba dbát na bezpečnost vašich skriptů, různé zkratky jako XSS, CSRF nebo třeba SQL Injection jsou vám jistě známé.

Při tom stačí velmi málo, abyste jim zabránili. Ověřujte veškeré uživatelské proměnné a pro různé případy escapujte obsah podle potřeby.

S tímto okruhem je často spojena jedna otázka, a to jestli povolit HTML v uživatelských formulářích. V tomhle ohledu je moje stanovinsko ne, všechny způsoby filtrování značek nejsou stoprocentní a už vůbec nejsou flexibilní. Na místě je použít nějaký alternativní značkovací jazyk, jako je Texy nebo vlastní implementace známého BBCode

Závěřem

Pokud tvoříte nějakou aplikaci, piště ji s co nejlepším svědomím a snažte se dodržet všechny principy, které jsem tu sepsal. Zároveň se ale nebojte své nedokonalosti, mnoho mých skriptů by někdo napsal mnohem lépe a už mnohokrát by pomohl kritický pohled jiného člověka. Nebojte se vaši práci konzultovat s někým jiným a nechat si poradit s efektivnějšími postupy.