Kdy už je superpresenter a kdy ještě není?

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
Berry
Začátečník | 70
+
0
-

Kdy už je superpresenter a kdy ještě není? To mi ted vrta hlavou. Mam statickej web pouze s basepresenterem a homepagepresenterem. V base presenteru mam jen texy. Ale v homepage mam uz emailovy formular. Dal chci pridat nejakou drobnost na galerii a jeste k te galerii strankovac. Nebude toho uz moc na jeden presenter?

Mikulas Dite
Člen | 756
+
0
-

Na dotaz define:superpresenter mi ani google nic nevrátil. Chápu, co myslíš, ale je to hodně subjektivní. Formulář můžeš třeba dát to vlastní třídy, ale jestli je to krátké (což jenom email asi je), tak to nemá moc cenu. Galerie se dá udělat jako celý modul, jestli je to jenom kreslení obrázku v šabloně, tak to v presenteru zůstat může. Jako jediné měřítko mě napadá délka kódu, což pro moje presentery je třeba 150 řádků a moc víc už bych tam nedával. Ale je to úplně na tobě. Stačí důsledně dodržet MVC.

Honza Kuchař
Člen | 1662
+
0
-

Také vůbec netuším o co jde. ;)

Berry
Začátečník | 70
+
0
-

Honza Kuchař napsal(a):

Také vůbec netuším o co jde. ;)

ukázka z „vytvoření presenteru“

Netvořte superpresentery (superpresenter je presenter, který dělá všechno)
Snažte se mít co nejmenší počet presenterů
Netvořte superakce (superakce je akce, která dělá činnost několika akcí)
Snažte se mít co nejmenší počet akcí v 1 presenteru
Struktura aplikace musí být jasná a srozumitelná (jakmile vám jako vývojáři jasná být přestane, je něco špatně)
Pokud mají některé presentery společnou část chování (nebo nějaké akce), definujte abstraktního předka těmto presenterům a toto chování (či akce) dejte do něho.
Správná struktura presenterů má vždy buď větve (abstraktní presentery) nebo listy (finální konkrétní presentery od nichž se už dále nedědí)

Pravidla 5 – 7 jsou docela v pořádku, problém je s pravidly 1 až 4, ta si totiž odporují… Co s tím?

Mikulas Dite
Člen | 756
+
0
-

Aha, to psal Inza, takže se už asi těžko dovíme, co tím přesně myslel.
Srozumitelnější by asi bylo:

  • Co nejméně presenterů, ale raději víc, než chumel v jednom

Analogicky akce.

Editoval Mikulas Dite (26. 3. 2011 19:49)

kravčo
Člen | 721
+
0
-

Berry napsal(a):

Pravidla 5 – 7 jsou docela v pořádku, problém je s pravidly 1 až 4, ta si totiž odporují… Co s tím?

Neodporujú. Upozorňujú na fakt, že ani jeden extrém nie je dobrý. Skrátka treba nájsť zdravý stred: málo prezenterov, ktoré robia tú svoju vec a robia ju dobre :)

Tharos
Člen | 1030
+
0
-

Berry napsal(a):

Správná struktura presenterů má vždy buď větve (abstraktní presentery) nebo listy (finální konkrétní presentery od nichž se už dále nedědí)

Tohle je postarší Davidovo rada, u které mě vždycky zajímalo, zda ji lidé dodržují… Programujete takhle? Chci říct: máte striktně všechny presentery s abstract nebo final? Co si o tom myslíte?

Editoval Tharos (27. 3. 2011 12:56)

22
Člen | 1478
+
0
-

používám abstract a ve filesystému si je dokonce značím ‚@‘, přiznám se, že final občas vynechám asi :-)

jtousek
Člen | 951
+
0
-

Abstract u presenterů používám, final tam sice napsané nemám, ale v podstatě final jsou.

Jan Tvrdík
Nette guru | 2595
+
0
-

Tharos wrote: Programujete takhle? Chci říct: máte striktně všechny presentery s abstract nebo final?

Ano.

Nox
Člen | 378
+
0
-

Ano…i když teda moc sem toho zatim nevytvořil, ale tohodle se držim striktně a zatím nebyl problém

jarks
Člen | 94
+
0
-

Mikulas Dite napsal(a):…150 řádků a moc víc už bych tam nedával.

Páni. Můj nejvíc největší presenter jich má 1000 a kousek. Nejsem na to hrdý, ale jedná se o stránku se zobrazením detailů položky a na každý detail se dá kliknout a něco s tím udělat. To je spousta handlerů a továrniček (editace, mazání) + třeba generování PDF dokumentů a tak dál.

Nevím, co bych s tím mohl udělat, všechno to patří k sobě. Žádné výkonové problémy s tím nejsou.

Mikulas Dite
Člen | 756
+
0
-

Výkonový problém z toho určitě nebude, paradoxně by čistě funkcionální kód bez OOP byl rychlejší. Jde o to, že v obrovském souboru je nepořádek a špatně se udržuje.

Třeba detail položky je ideální kandidát na vlastní komponentu – handlery se přesunou, ale nějaká hlubší rada závisí problém od problému. Například na generování pdf se dá udělat wrapper v modelu.