Kdy už je superpresenter a kdy ještě není?
- Berry
- Začátečník | 70
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
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.
- Berry
- Začátečník | 70
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
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
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
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)
- Jan Tvrdík
- Nette guru | 2595
Tharos wrote: Programujete takhle? Chci říct: máte striktně všechny presentery s
abstractnebofinal?
Ano.
- jarks
- Člen | 94
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
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.