You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Howard M. Lewis Ship (JIRA)" <de...@tapestry.apache.org> on 2008/02/24 03:47:20 UTC
[jira] Closed: (TAPESTRY-2025) Centralize page/component class
resolution logic
[ https://issues.apache.org/jira/browse/TAPESTRY-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship closed TAPESTRY-2025.
------------------------------------------
Resolution: Won't Fix
Assignee: Howard M. Lewis Ship
I think the correct way to address your access control scenario is by plugging into the ComponentEventRequestHandler and PageRenderRequestHandler pipelines. These pipelines support filters and are invoked only once the details of the request (i.e., page name, component, contexts, etc.) is established.
> Centralize page/component class resolution logic
> ------------------------------------------------
>
> Key: TAPESTRY-2025
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2025
> Project: Tapestry
> Issue Type: Improvement
> Components: Framework, tapestry-core
> Affects Versions: 5.0, 5.0.7, 5.0.8
> Reporter: Chris Lewis
> Assignee: Howard M. Lewis Ship
>
> The PageRenderDispatcher and ComponentActionDispatcher each have to decipher the component or page being requested. The resolution of the associated class in each case is essentially the same. I'm working (again) on a transparent access control system that must do the same thing, so I've basically copy/pasted this logic. It would seem to make sense (and also be convenient for me) to centralize this logic somewhere - probably as a static method. This would also insulate code like mine against breakage.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Closed: (TAPESTRY-2025) Centralize page/component class
resolution logic
Posted by Chris Lewis <bu...@gmail.com>.
Thanks I will look into that.
chris
Howard M. Lewis Ship (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/TAPESTRY-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Howard M. Lewis Ship closed TAPESTRY-2025.
> ------------------------------------------
>
> Resolution: Won't Fix
> Assignee: Howard M. Lewis Ship
>
> I think the correct way to address your access control scenario is by plugging into the ComponentEventRequestHandler and PageRenderRequestHandler pipelines. These pipelines support filters and are invoked only once the details of the request (i.e., page name, component, contexts, etc.) is established.
>
>
>> Centralize page/component class resolution logic
>> ------------------------------------------------
>>
>> Key: TAPESTRY-2025
>> URL: https://issues.apache.org/jira/browse/TAPESTRY-2025
>> Project: Tapestry
>> Issue Type: Improvement
>> Components: Framework, tapestry-core
>> Affects Versions: 5.0, 5.0.7, 5.0.8
>> Reporter: Chris Lewis
>> Assignee: Howard M. Lewis Ship
>>
>> The PageRenderDispatcher and ComponentActionDispatcher each have to decipher the component or page being requested. The resolution of the associated class in each case is essentially the same. I'm working (again) on a transparent access control system that must do the same thing, so I've basically copy/pasted this logic. It would seem to make sense (and also be convenient for me) to centralize this logic somewhere - probably as a static method. This would also insulate code like mine against breakage.
>>
>
>