Ale: Spring MVC absolutne neriesi, v com bude napisany view. JSP? Freemarker? JasperReports? RSS? Staci, ze view rendered dostane modelovu mapu a ako ju zrenderuje je na nom. Nette podporuje primarne PHP, ako je to s inymi vrstvami?
Podobně to funguje i v Nette. Zítra by měl vyjít další díl seriálu, který se týká právě renderování šablon, takže tam to bude popsáno podrobně.
Kontroler. Spring MVC razi zasadu, ze obsluzne triedy maju byt jednoduche, najlepsie bezne triedy s anotaciou. (Anotacia je ekvivalentna marker interfacu bez metod).
Anotace PHP prakticky nezná. Zkusil jsem s nimi přijít v Nette, ale narazilo to na technické a „filosofické“ problémy, takže se držím zpět ;)
Odkazovanie. „redirect:“ je skratka pre pohodlnych. Pokojne mozete vratit specialny RedirectView, kde uvediete logicke meno viewu a model (presny ekvivalent „->redirect()“).
Tady mi šlo spíš o ty URL, které Nette generuje dynamicky. Tedy ačkoliv když vrátím RedirectView, tak se jich nezbavím. (teda jestli to dobře chápu).
Tu by som podotkol, ze netreba mat totalnu paranoju z XML. Bezna springova aplikacia ma aj tak XML subor pre dependency injection, cize tam je to jedno.
Ano, to je věc zvyku. Ve světě PHP jsou preferovanější INI soubory, nejspíš proto, že samotné PHP se tímto způsobem konfiguruje.
(a pozor: DI je velmi dobry pattern, ktory vyvoj velkych aplikacii sprehladnuje).
Bezpochyby!
ako je mozne pouzivat vlastne formulare (Nette generuje kod formularov dynamicky, toto Spring MVC nema, view vrstvu nechava na vyber implementatora)
V podstatě lze volit v řadě úrovní od prostého manuálního vykreslení a obsluhy formuláře až po plně automatické v režii objektu Form (například automatická obsluha + manuální vykreslení v šabloně). Asi největší vývoj probíhá na straně automatického vykreslování, protože je to pohodlné (čti: uživatelé to chtějí), ale zároveň by to mělo být co nejlépe konfigurovatelné (čti: každý formulář vypadá úplně jinak).
