[
https://issues.apache.org/jira/browse/TAP5-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13056388#comment-13056388
]
Vjeran Marcinko commented on TAP5-1284:
---------------------------------------
I have to add comment about this since this is maybe the biggest design issue I
have with Tapestry pages overall.
The general problem is that mechanism for *configuring page*, by accepting
request parameters: in one of following ways:
@PageActivationContext or
@ActivationRequestParameter or
"activate" handler
, is mixed with the only place one can *execute post-configuration logic* in a
page, and that is "activate" handler.
Typical case is when one wants to execute some page-hierarchy security check
that depends upon parameters from child classes, such as in case above. There
are many other cases as well.
So having some post-activate event should be delightful since it would solve
this issue.
Whenever I brought this issue on mailing list, I got answer that using
subclassing for common page processing logic is no-good design issue
(subclassing is evil), thus I should use intercepting via filters, which
although have some nice advantages, but also bring some big drawbacks for many
cases).
> When using @PageActivationContext and override a no-args activate event
> handler of parent page, the handler called too soon
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: TAP5-1284
> URL: https://issues.apache.org/jira/browse/TAP5-1284
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.2.0
> Reporter: Alexander Gavrilov
> Assignee: Howard M. Lewis Ship
> Priority: Critical
>
> It appears that the overrided onActivate() method is called before the
> @PageActivationContext logic, which means the following can fail:
> public class BasePage {
> private MyEntity entity;
>
> protected void setEntity(MyEntity entity) {
> this.entity = entity;
> }
>
> protected void onActivate() {
> if (entity == null) throw new RuntimeException("Entity not found.");
> }
> }
> public class ConcreteClass {
> @PageActivationContext
> private MyEntity entity;
> protected void onActivate() {
> setEntity(entity);
> super.onActivate();
> }
> }
> Workaround is do not use methods overriding.
> The problem is the consecuence of Howard's approach: "if the child class
> *overrides* a method of the parent, then the overridden method will be
> invoked only by the parent class". When Tapestry performs transformation it
> skips OnEventWorker advice, which invoke event handler method of subclass and
> add it only for parent class. And required for @PageActivationContext chain
> of invocation breaks. My approach is that if some class override some event
> handler method of some class then Tapestry should stop advaicing parent class
> method invocation and should rely on subclass method definition and is the
> subclass implementor responibility to invoke parent class method.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
