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.
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) 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 databázi,
nastavit parametry šablon 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á funkčnost (například pohled) presenteru bude v celé struktuře jedinečná.
