You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "David H. DeWolf (JIRA)" <ji...@apache.org> on 2006/11/02 21:49:57 UTC
[jira] Assigned: (SB-64) Remove URLViewPreparer Support
[ http://issues.apache.org/struts/browse/SB-64?page=all ]
David H. DeWolf reassigned SB-64:
---------------------------------
Assignee: David H. DeWolf
> Remove URLViewPreparer Support
> ------------------------------
>
> Key: SB-64
> URL: http://issues.apache.org/struts/browse/SB-64
> Project: Sandbox
> Issue Type: Improvement
> Components: Tiles
> Reporter: David H. DeWolf
> Assigned To: David H. DeWolf
>
> We never came up with a good use case for the URLViewPreparer. In essence, all it does is a pageContext.include(uri). Why do we need to run that through tiles? Preparers should be limited to manipulating the ComponentContext.
> Having it forces us to support two attributes (preparerUrl and preparerClass in the tld, name and type in the Preparer). Getting rid of it would allow us to simplify things.
> Antonio Petrelli wrote:
> >>
> >> Well, it's the controllerUrl I have the most trouble with. I don't
> >> have any problem with declaring a class to be executed to prepare the
> >> view. But an URL? An URL will always resolve to something - return a
> >> response - and I don't think these view preparers should return
> >> anything or resolve anything. They should simply be capable of
> >> manipulating the context - preparing the context for the view (IMHO).
> >
> > You're right, also because if you specify the URL directly in the
> > "template" attribute you have the same result. So maybe "controllerUrl"
> > should not be there.
> >
> > Ciao
> > Antonio
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira