[ 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
