On Tue, 02 Nov 2010 12:33:13 -0200, Vjeran Marcinko
<vjeran.marci...@email.t-com.hr> wrote:
Yes, I'm aware of "subclassing is evil" rule,
When a tool is used we can't forget that it has some design decisions. It
was meant to be used in some ways and not in others. I guess you're
stepping out a little of the Tapestry philosophy. You have all the right
to do that, but don't forget it wasn't meant to be used that way. :)
Something I personally find odd is to have two different object ids being
used in the same page to edit or view the same object. Of course, I don't
know your requirements, but that's something I wouldn't do, as the same
thing would have two or more URLs.
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.
That's a compromise, no doubts about it.
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).
You don't need to parse yourself: use the ComponentEventLinkEncoder
service and its decodeComponentEventRequest() and
decodePageRenderRequest() methods. For conversions, use the TypeCoercer
services. That's exactly what Tapestry internally does.
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...
Use the ApplicationStateManager service for that. Again, that's exactly
what Tapestry internally does. @SessionState fields are replaced by method
invocations, so there's no difference in directly accessing fields. They
don't even exist in runtime since T5.2. Don't forget that @SessionState is
stored by object type, not page or field name. @Persist are.
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.
Please rethink your arguments after reading this message and let's see
what happens. :) Nice discussion, by the way. :)
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
