You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Max Starets (JIRA)" <de...@myfaces.apache.org> on 2010/02/23 20:00:28 UTC
[jira] Created: (TRINIDAD-1735) Trinidad 2: Provide
ViewDeclarationLanguageFactory wrapper instead of overriding
ViewHandler.getViewDeclarationLanguage()
Trinidad 2: Provide ViewDeclarationLanguageFactory wrapper instead of overriding ViewHandler.getViewDeclarationLanguage()
-------------------------------------------------------------------------------------------------------------------------
Key: TRINIDAD-1735
URL: https://issues.apache.org/jira/browse/TRINIDAD-1735
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 2.0.0.2-core
Reporter: Max Starets
Priority: Minor
We override ViewHandler.getViewDeclarationLanguage() to return null VDL for the internal views and to call inro PageResolver before determining the VDL.
The problem is our override does not get called during ViewHandler.createView() because the delegate ViewHandler just calls getViewDeclarationLanguage on itself. This is not causing any serious problems today because both Facelets and JSP VDLs call into the same base implementation of createView(). However, the right solution will be to stop overriding getViewDeclarationLanguage() on the ViewHandler and start wrapping ViewDeclarationLanguageFactory instead, so we can start overriding getViewDeclarationLanguage() there.
According to JavaDoc, ViewHandler.getViewDeclarationLanguage() is merely a convenience method. As such it should have been made final in the JSF API, and problems like these would be easily prevented.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1735) Trinidad 2: Provide
ViewDeclarationLanguageFactory wrapper instead of overriding
ViewHandler.getViewDeclarationLanguage()
Posted by "Max Starets (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-1735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Max Starets updated TRINIDAD-1735:
----------------------------------
Status: Patch Available (was: Open)
> Trinidad 2: Provide ViewDeclarationLanguageFactory wrapper instead of overriding ViewHandler.getViewDeclarationLanguage()
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: TRINIDAD-1735
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1735
> Project: MyFaces Trinidad
> Issue Type: Bug
> Affects Versions: 2.0.0.2-core
> Reporter: Max Starets
> Assignee: Max Starets
> Attachments: trinidad-1735.diff
>
>
> We override ViewHandler.getViewDeclarationLanguage() to return null VDL for the internal views and to call inro PageResolver before determining the VDL.
> The problem is our override does not get called during ViewHandler.createView() because the delegate ViewHandler just calls getViewDeclarationLanguage on itself. This is not causing any serious problems today because both Facelets and JSP VDLs call into the same base implementation of createView(). However, the right solution will be to stop overriding getViewDeclarationLanguage() on the ViewHandler and start wrapping ViewDeclarationLanguageFactory instead, so we can start overriding getViewDeclarationLanguage() there.
> According to JavaDoc, ViewHandler.getViewDeclarationLanguage() is merely a convenience method. As such it should have been made final in the JSF API, and problems like these would be easily prevented.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1735) Trinidad 2: Provide
ViewDeclarationLanguageFactory wrapper instead of overriding
ViewHandler.getViewDeclarationLanguage()
Posted by "Max Starets (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-1735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839848#action_12839848 ]
Max Starets commented on TRINIDAD-1735:
---------------------------------------
Changing the priority to "Major", as it turns out that ViewHandler.renderView() does not call our override either.
Since we have to make the ViewDeclarationLanguageFactory aware of the InternalViews, it makes sense to move all logic related to the InternalViews from ViewHandlerImpl to the new ViewDeclarationLanguageFactoryImpl. This will allow us to expose InternalView handling as a VDL, which is a cleaner solution consistent with the JSF 2 architecture. The only issue is that ViewDeclarationLanguage does not expose writeState(0, so we will have to leave a minimal amount of the InternalView-related code in the ViewHandlerImpl.
> Trinidad 2: Provide ViewDeclarationLanguageFactory wrapper instead of overriding ViewHandler.getViewDeclarationLanguage()
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: TRINIDAD-1735
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1735
> Project: MyFaces Trinidad
> Issue Type: Bug
> Affects Versions: 2.0.0.2-core
> Reporter: Max Starets
> Assignee: Max Starets
> Attachments: trinidad-1735.diff
>
>
> We override ViewHandler.getViewDeclarationLanguage() to return null VDL for the internal views and to call inro PageResolver before determining the VDL.
> The problem is our override does not get called during ViewHandler.createView() because the delegate ViewHandler just calls getViewDeclarationLanguage on itself. This is not causing any serious problems today because both Facelets and JSP VDLs call into the same base implementation of createView(). However, the right solution will be to stop overriding getViewDeclarationLanguage() on the ViewHandler and start wrapping ViewDeclarationLanguageFactory instead, so we can start overriding getViewDeclarationLanguage() there.
> According to JavaDoc, ViewHandler.getViewDeclarationLanguage() is merely a convenience method. As such it should have been made final in the JSF API, and problems like these would be easily prevented.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.