You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Jesse Kuhnert (JIRA)" <ta...@jakarta.apache.org> on 2006/03/10 03:10:39 UTC

[jira] Resolved: (TAPESTRY-209) order of validate & activateExternalPage

     [ http://issues.apache.org/jira/browse/TAPESTRY-209?page=all ]
     
Jesse Kuhnert resolved TAPESTRY-209:
------------------------------------

    Resolution: Won't Fix
     Assign To:     (was: Tapestry Developer List)

> order of validate & activateExternalPage
> ----------------------------------------
>
>          Key: TAPESTRY-209
>          URL: http://issues.apache.org/jira/browse/TAPESTRY-209
>      Project: Tapestry
>         Type: Bug
>   Components: Framework
>     Versions: 3.0
>  Environment: Operating System: All
> Platform: All
>     Reporter: joe panico

>
> I'm proposing that the current implementations of
> ExternalService/ExternalCallback are somewhat broken for real-world
> applications. The problem is the order in which validate() and
> activateExternalPage(parameters, cycle) are called on the target IExternalPage.
> Currently, the External Service/callback implementations follow this sequence:
> 1) cycle.activate(page);
> activate() will trigger a call to validate()
> 2) page.activateExternalPage(parameters, cycle);
> This means that validate(IRequestCycle) will be called on a target
> IExternalPage _before_ the state has been set (activateExternalPage) on that
> page. For most of my pages, I'm performing _stateful_ page validation, in
> other words validate has to check not only that a particular user is allowed
> to see a particular ExternalPage, but also that the user is allowed to see
> particular _target state (content)_ in that page. So I've been using my own
> copy of ExternService that simply switches the order of these operations.
> A concrete example:
> I have an ExternalPage which represents a page in a Photo Album. The identities
> of the Photo and Photo Album which are the target (content) of this ExternalPage
> are encoded in the URL (they are ExternalPage parameters). 
>  
> This page is "protected", meaning that it may require the user authenticate
> before viewing an album. The Page may also require _authorization_, meaning that
> only certain users are allowed to view that particular album in that particular
> page. In other words, the state (album id) associated with that page is required
> in order to perform page.validate().
> I propose an easy fix for this problem. Simply reorder the validate and
> activateXternalPage operations. The new implementation would look like this:
> ...
> 		Object[] parameters = getParameters(cycle);
> 		cycle.setServiceParameters(parameters);
> 		page.activateExternalPage(parameters, cycle);
> 		cycle.activate(page);
> 		// Render the response.
> 		engine.renderResponse(cycle, output);
> ...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org