Hi, Vjeran!
Hi Thiago!
Almost any kind of cross-page solution, as this scenario, is much better implemented as a ComponentRequestFilter. You can put all the logic in a single, easily unit tested class and with almost no effort (just a contribution to the ComponentRequestHandler service) apply it to all page requests, both render and action ones.
Yes, I'm aware of "subclassing is evil" rule, but cross-cutting concerns such as I mentioned are sometimes very hard to realize via ComponentRequestFilter since these filters don't have same features as Tapestry pages. Even when desired functionality can be achieved, you don't have same amount of compile-check as when you do it via page superclass.
For example, sometimes this cross-cutting logic needs to access @PageActivationContext fields directly, but I cannot use this annotation in filter implementations (maybe by parsing URLs, but that's cumbersome and not compile-safe). Fields annotated with @SessionState are also not available (maybe available through some global Tapestry service by some (?!) name, but not directly referencing class field)...etc...
For simple page authrozation based on some @Secured-like page annotation, ComponentRequestFilter are probably a perfect fit, but for some non-trivial cases, it seems to me this is too heavyweight solution. Sometimes I have a small cross-cutting logic only reused in 2-3 pages, and maybe a dozen of such in whole web app, so it feels a bit cumbersome to use ComponentRequestFilters for such cases, so superclass is a good fit there.
Cheers, Vjeran --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
