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/01 14:43:57 UTC
[jira] Created: (SB-64) Remove URLViewPreparer Support
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
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
[jira] Assigned: (SB-64) Remove URLViewPreparer Support
Posted by "David H. DeWolf (JIRA)" <ji...@apache.org>.
[ 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
[jira] Resolved: (SB-64) Remove URLViewPreparer Support
Posted by "David H. DeWolf (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SB-64?page=all ]
David H. DeWolf resolved SB-64.
-------------------------------
Fix Version/s: 2.0
Resolution: Fixed
Fixed.
> 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
> Fix For: 2.0
>
>
> 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