Sraz Nette Framework v pátek 18. 7.

Sdružení rodičů a přátel Nette Frameworku vás srdečně zve na tradiční členskou schůzi vývojářů webových aplikací. Program bude zahájen volbou nástěnkáře, bude následovat recitace básní oslavujících Nette Framework, poplácávání se, kritizování a posmívání se ostatním frameworkům a konzumace alkoholických nápojů dle vlastního výběru.

Účast nutná!

• termín: pátek 18. července od 16 hodin
• místo konání: Brno, Schnitzel House na Běhounské 15 (mapka)

Pokud máte chuť probrat věci týkající se vývoje webových aplikací v Nette Frameworku, ale také vývoje frameworku samotného, budu rád, když dorazíte. Jde čistě o neformální setkání. Abych mohl vybrat a zamluvit nějaký prostor (salonek v restauraci blízko centra – máte tip?), potřeboval bych vědět, kolik lidí asi tak dorazí, takže prosím svou účast potvrďte v komentářích. Jestli pojedete autem a můžete někoho vzít, napište svůj kontakt a odkud jedete.

Těším se!

Návrh struktury presenters/views

Jak správně navrhnout strukturu aplikace psané v Nette v pojmech presenter a view (resp. action).

Presenter vs. view

Pro objektový návrh presenterů by se měla dodržovat stejná pravidla, která platí pro OOP jako takové. Konkrétně mám na mysli tezi, že objekt by měl plnit pouze jeden úkol.

Presentery s více pohledy (views) nebo akcemi (actions) svádějí tento princip porušovat. Svým způsobem i sebesložitější aplikaci mohu narvat do jednoho presenteru s obrovským počtem pohledů. A každý z nich bude používat jen svůj okruh komponent a parametrů. Asi cítíte, že to je špatný přístup.

Druhým extrémem je pro každý pohled vytvořit vlastní presenter. Ano, jde také o extrém, ale z hlediska návrhu poměrně čistý (dokonce předchozí verze Nette tak byly koncipované a třída Presenter se jmenovala Page).

Jakou zvolit cestu mezi oběma mantinely? Doporučuji řídit se tímto pravidlem:

V jednom presenteru sdružujte jen ty pohledy, které používají společné komponenty a persistentní parametry.

V tu chvíli začne presenter plnit jen jeden úkol – obhospodařovat své komponenty a persistentní parametry. Pravidlo má navíc příjemný důsledek – automatické předávání persistentních parametrů v Nette bude pracovat velmi efektivně a pouze ve váš prospěch.

Vytvořte hierarchii presenterů

Všechny presentery ve vaší aplikaci by měly tvořit hierarchii. Přinejmenším vytvořte jednoho společného předka. Díky tomu se vyhnete opakování stejného kódu na více místech aplikace. Společný předek může v metodě startup() zajistit připojení k modelu nebo zkontrolovat uživatelská oprávnění.

S hierarchií úzce souvisí automatické předávání persistentních parametrů. Pokud potřebujete, aby se určitý parametr automaticky přenášel mezi skupinou presenterů, tak ho deklarujte na úrovni jejich předka.

Buď final, nebo abstract

Pokuste se hierarchii presenterů navrhnout tak, aby každý z nich představoval buď list, nebo větev. Listem je myšlen presenter, od kterého už nelze odvozovat nové třídy (je deklarovaný pomocí klíčového slova final, na obrázku označen jako leaf). Větev je naopak presenter, který lze použít pouze k odvozování (je deklarovaný jako abstract). Nette nedovolí abstraktní presentery vůbec adresovat.

Tato technika zajistí, že každá akce presenteru bude v celé struktuře jedinečná.

Laděnka, jak se vám líbí?

Laděnka je užitečnou každodenní pomocnicí PHP programátora. Její oficiální jméno zní Nette\Debug.

Každý ladič je dobrým kamarádem s funkcí var_dump, která podrobně vypíše obsah proměnné. Bohužel v prostředí HTML výpis pozbude formátování a slije se do jednoho řádku, o sanitizaci HTML kódu ani nemluvě. V praxi je nezbytné var_dump nahradit šikovnější funkcí. Tou je právě Debug::dump()

$arr = array(10, 20.2, TRUE, NULL, 'hello');

Debug::dump($arr);
// včetně jmenného prostoru Nette\Debug::dump($arr);

vygeneruje výstup:

array(5) {
  [0] => int(10)
  [1] => float(20.2)
  [2] => bool(true)
  [3] => NULL
  [4] => string(5) "hello"
}

Dalším užitečným nástrojem ladiče jsou stopky s přesností na mikrosekundy:

Debug::timer();

// princi můj malinký spi, ptáčkové sladce již sní...
sleep(2);

$elapsed = Debug::timer();
// $elapsed ≈ 2

Tohle všechno jsou sice užitečné drobnosti, skutečným killerem je však jiná Laděnčina vlastnost. Zpráva o nezachycené výjimce nebo chybě poskytuje vývojáři důležité informace o tom, kde a proč k ní došlo. Standardní výstup v PHP vypadá asi takto:

Pusťme však ke slovu Laděnku. Po aktivaci příkazem Debug::enable() nám předvede svou nejvíce sexy polohu:

Takto vypadá výjimka, takto vypadá vygenerovaná chyba. To je pak jiné ladění, co?

Snad nemusím dodávat, že vypisování chyb se nesmí nikdy dostat na produkční server. Je to výborná společnice na pracovišti, ale nikdy ji nesmíme brát sebou ven. Je totiž děsně ukecaná a vyzradí na vás úplně všechno (nicméně kdyby k tomu náhodou došlo, má integrovaný systém pro skrytí citlivých políček, např. hesel). Na produkčním serveru je však možné nechat výpisy ukládat do adresáře nebo odesílat administrátorovi emailem.

→ Download: Nette\Debug.zip, licence, překlad

(doplněno: mám na vás prosbu…)

Nette\Object - taťka všech objektů

Je známo, že objekty se do jazyka PHP dostaly spíš jako nezvaní hosté. Docela příznačným rozdílem mezi jazykem, který byl jako objektový již navrhován, a jazykem, který se jím stal k velkému překvapení samotných tvůrců, je v absenci resp. přítomnosti společného předka všech tříd. Object Pascal deklaruje TObject, DOT.NET má System.Object a v Javě nebo Ruby stojí v hierarchii nejvýše Object (je delikátní, že nejzákladnější třída bývá pojmenována objekt). V PHP nic takového neexistuje.

Základní třída obvykle deklaruje metody pro sebereflexi. Například metodu vracející název třídy. Je to sice detail, ale vždycky mi připadalo tuze ošklivé mixovat hezký objektový kód s voláním pro-objektové funkce get_class:

$a = $obj->myMethod();
$class = $obj->getClass(); // hezké
$class = get_class($obj); // ošklivé

…pokračování

Kdy bude Nette aneb

Titulky obsahující slovo „aneb“ mi vždycky připadaly divné. A tento je ze všech úplně nejdivnější. Že jo?

Téměř každý den dostávám dotaz, kdy bude Nette. Už jsem si říkal, že si připravím automatickou odpověď, nebo si napíšu do messengera plugin, který to za mě bude vyřizovat sám. Ale nakonec jsem šáhl po blogu. Takže, slyšte…

Rozpaky programátora Svatopluka

Je krásný vlahý den, tři hodiny ráno, a vy si zlehka programujete novou báječnou webovou aplikaci. Důležitou roli v ní hraje vaše šikovná knihovna Manipulator. Když tu si najednou všimnete, že volání metody $manipulator->appendFor(TRUE, $objA) má jednu kosmetickou vadu. Teda vlastně dvě. Jednak samotný název metody je nešťastný, vhodnější by bylo appendTo nebo pouhé append. A za druhé – to pořadí argumentů by mělo být opačné. No jistě, kolikrát už jste se sám spletl. Je to jasné, $manipulator->append($objA, TRUE) vypadá mnohem lépe. Navíc druhý parametr bývá v 99 % případů TRUE, takže ho můžeme dát jako volitelný, s touto výchozí hodnotou.

Motivace na drobný refactoring jako vyšitá.

Co zatím nevíte…

Něco vám musím prozradit. Knihovna Manipulator je velmi populárním open-source projektem. Používají ho tisíce vývojářů. A vy jste jeho autorem.

Jo, kdybyste byl samotář, co si kód píše a používá sám, přejmenování metody a prohození parametrů by byla brnkačka. No, uvažujete, na to by se dal napsat regulární výraz. Prográmkem (samozřejmě opět vlastní výroby) Search & Replace si projedete všechny své zdrojáky a jednotlivé záměny budete ručně potvrzovat. To pro sichr.

Odhadem – bajvoko – za čtvrt hodinky je to hotové.

Ale jak jsem zmínil, Manipulator je big fasa project. Takže přemýšlíte, jestli vážně tu změnu udělat:

Neváhal bych, jenže co ty tisíce uživatelů? Způsobím jim komplikace, práci navíc. A přitom jde vlastně o hloupost.

Jenže, mně se prostě appendFor nelíbí, mně to tam vadí. Chci to změnit. Manipulator používá stále víc programátorů a čím později změnu udělám, tím víc jich to postihne.

Nebo raději počkám na větší update, až se změní velké číslo verze.

Ale kurnik žádné závazky přece nemám, prostě to změním a hotovo. Napíšu to do changelogu, programátoři si to přečtou a svůj kód si holt budou muset změnit.

Ach jo, víš, jak to dopadne, budeš odpovídat na tisíce dotazů „hele, updatnul jsem si Manipulator a píše mi Fatal error: Call to undefined method appendFor, co stím?“

Doprkýnka, pošlu je do patřičných míst v changelogu.

Ale nepošleš. Jen si vzpomeň, kolikrát jsi sám aktualizoval software a nikdy jsi nestudoval changelog. Sám to neděláš a po ostatních to chceš?

Dobře, ale co já z těch „ostatních“ mám? Dávám jim svůj těžce vydřený software zdarma – a co je zdarma, to nikdo neocení. Píšu dokumentaci, odpovídám na stovky dotazů a výsledek je, že se nervuju, když chci přejmenovat jednu blbou funkci.

Nebo vznesu návrh, uvidíme, co na to řeknou uživatelé.

No co asi. Zrovna minulý týden jsi přejmenoval dvě klíčové třídy. To bude zase radosti… Vykašli se na to.

Stop!

A tady příběh zastavíme. Jako na videu. Od této chvíle je to na vás! Jak se má programátor Svatopluk Kuřátko rozhodnout?

1. změnit název metody a prohodit pořadí parametrů
2. na úpravu se vykašlat

Posílejte SMS ve tvaru HLA DGX A nebo B. Jste to vy, kdo ovlivní další děj!

Málem bych zapomněl. Vy vlastně chcete vědět, kdy bude Nette, že? Já se tak rozepsal, že mi to skoro vypadlo. Uff, to bylo o fous.