Portál AbcLinuxu, 29. října 2025 02:37

Jinak mi ale ZF nepříjde zle vymyšlený.
Velkou část návrhu tvoří právě optimální "napasování" požadavků na specifika daného frameworku (ač to tak jistě zní, zdaleka ne vždy je to napasovávání v negativním smyslu).
Pokud sklouznu ke krátké filozofii - prošel mi rukama podobný set jazyků a rozhodně mi nejvíc sedla Java - pokud bych mohl volit, píšu v ní. Jenže na to musí být vhodné projekty, zákazníci, atd. atp. PHP vzhledem ke svému zaměření dost komplikuje psaní kvalitního kódu (nebo spíš nedělá nic pro něj). Ostatně PHP vzniklo jako jednoduchý jazyk, který se běžně pra*il do jednoho souboru s HTML... co k tomu dodat?
ad. MVC / souhlas. Ono není triviální ani navrhnout aplikaci tak, aby tahle písmenka ctila, natož navrhnout framework, který by tuhle problematiku řešil obecně a dobře... ve finále je stejně alfou i omegou design samotné aplikace.
Ja se toho nebojim a kdyz uz nic, tak me to ponauci. A kdyby preci neco, bude z toho uzitek, takze prace se nebojim, uz jsem napsal tolik zbytecneho kodu, ktery uz se nepouziva, jako molokdo jiny, neztratil jsem chut, tak proc nepokracovat
Javu jsem nezkusil, C# je dost podobny jazyk, standartni tridy (az na ty uplne zakladni) jsou ale jine. Mozna bych se mohl podivat na Spring, jak mi doporucil ladicek nize, za to nic nedam.
ad MVC - pokud to nepodporuji tridy ve frameworku, nemuze ani aplikace. Pokud to aplikace podporuje, troufam si rict, ze uz to je (alespon na pul) framework. Ono k tomu modelu patri prave i ORM - tzn. nejaka DB abstrakce, nejakym zpusobem vzladnuty mapping z objektu/entity na radek v relacni databazi, nejakym zpusobem udelane zpetne napojeni z controlleru kvuli strankovani, nejakym zpusobem udelane mapovani do view, prez nejake widgety... problem je, ze MVC jako takove je teoreticka zalezitost a praxe je jinde a ta se ohyba a nekdy se stane, ze se cele MVC proleje a je z toho kus modelu v controlerru, kus view v modelu a kus controlleru v horsim pripade i v modelu i ve view a pak uz to neni MVC ale gulas, kde vsude je neco a nema to tam ve skutecnosti co delat. Na controller je jednoduche pravidlo, keep it skinny. Model je take vzdy jasny, co nepatri k logice problemu, nema tam co delat, na to jsou helpery, pripadne pro view decoratory, pro controller akce atd.. to uz je ozkousene a napsane v mnoha jazycich (Python, RoR, urcite i Java, .NET...) jen to PHP mi prijde ze mirne zaostava..
Pak se stane to, ze to bobtna a za par mesicu z toho je strudl a veskere vyhody OOP jsou ty tam a udrzitelnost nulova.
Ale mám ten jazyk rád - jen mi chybí pár jazykových vychytávek, ale dá se s tím žít
Component, která má víc než čtyři tisíce řádků a řeší snad úplně všechno. Můj nejoblíbenější příklad – fakt patří metoda setResponsePage do třídy Component? Wicket hodně využívá dědičnosti, takže ono to z pohledu příjemného používání dává smysl, ale nemůžu to nepovažovat za prasárnu
Component je dost komentářů, ale setResponsePage() bych očekával asi taky trochu jinde i když to má své opodstatnění i v rámci design pattern Composite, ale musel bych si asi něco napsat, abych to mohl hodnotit, každopádně zařadím si to do seznamu "k prozkoumání"
sloccount je to je bez komentářů něco přes 2000 řádků, což je pořád dost monstrózní. I když jsem samozřejmě viděl i větší.
Ale jestli chcete jiný příklad, můžu sloužit třeba generováním javascriptů v Javě uvnitř komponent sčítáním řetězců (i když práce s externími javascripty je ve Wicketu hodně pěkná). I když mám pocit, že v téhle oblasti se něco dělo, takže už to dneska možná neplatí.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.