On Thu, 24 Feb 2011 04:58:26 -0300, Vjeran Marcinko
<vjeran.marci...@email.t-com.hr> wrote:
Hello all,
Hi!
I just wanted to hear if current state of page configuration and
activation is the desired one?
What do you mean by page configuration?
(this is the reason for one of my architectural problems, but I don't
want to go into details here since it will boil down to - why don't I
use RequestFilters insted of page hiererchy for some common
preprocessing actions)
Page hierarchy is not as good as a solution as request filters or mixins.
Documentation states that page configuration via @PageActivationContext
and @ActivationRequestParameter fields is done prior to calling
"activate" handler, but it doesn't state what happens when one has page
hierarchy.
This isn't page configuration. This is receiving information from request
parameters.
With version 5.2.1 it changed in such way that these annotation are
kinda tied with "activate" and handled in bundle with it. For example,
when "activate" is being handled, Tapestry first takes superclass, sets
@PageActivationContext field and calls "activate" on it, then it takes
subclass, and again sets @PageActivationContext field and calls
"activate" on it. In other words, "activate" handler in superclass is
called prior to @PageActivationContext field in subclass.
Is this behaviour as it is supose to be?
I don't know, but I'd avoid having more than one method handling the same
event. As you're using subclassing, why don't you override the activate
event handler method instead of adding a new one?
--
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
