[jira] [Commented] (TAP5-1284) When using @PageActivationContext and override a no-args activate event handler of parent page, the handler called too soon

["Howard M. Lewis Ship (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TAP5-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13056230#comment-13056230 ] 

Howard M. Lewis Ship commented on TAP5-1284:
--------------------------------------------

I should have looked at this one more carefully before I started working on it.

The @PageActivationContext is in the child class.

The basic rule that parent class event handlers are invoked before child class event handlers still holds.

Thus the order of execution is the "activate" event on BaseClass, which is the invocation of BasePage.onActivate().  This is overridden in ConcreteClass, and fails.  If it didn't fail, then Tapestry would process the @PageActivationContext event handler in ConcreteClass, and skip the onActivate() method in ConcreteClass, because it is an override of a BasePage method. 

Short of introducing yet another event that would occur between the activate event and the other processing for the request (which might be a page render or a component event request), there isn't a way to express what you want in Tapestry.  

You could rip out the @PageActivationContext annotation and replace it with an onActivate(MyEntity) method that accomplished the same thing and it would be more clearly an error.

So in summary, the event handler is not called "too soon", it is called in the correct established order, which simply is not convenient for your code. 

I'm going to leave this issue open for a bit, and think about adding a "postActivate" event that would exist to support validations after the completion of the "activate" event.  However, once you open up one special case like that, you start to think in terms of something more general purpose ... such as exposing a more general way to defer some logic during the processing of an event (rather than, effectively, splitting one event into two, for timing purposes).

> 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