You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Pavitra Subramaniam (JIRA)" <de...@myfaces.apache.org> on 2010/10/19 00:08:28 UTC
[jira] Created: (TRINIDAD-1942) ViewDeclarationLanguageFactoryImpl
implementation should cache physical URI for the current viewId on the
ViewMap
ViewDeclarationLanguageFactoryImpl implementation should cache physical URI for the current viewId on the ViewMap
-----------------------------------------------------------------------------------------------------------------
Key: TRINIDAD-1942
URL: https://issues.apache.org/jira/browse/TRINIDAD-1942
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.0-alpha-2
Reporter: Pavitra Subramaniam
In an included page (or fragment) if a composite component gets used, the CompositeComponentTagHandler retrieves the logical viewId (context.getViewRoot().getViewId()) first and then gets its physical URI in order to determine the VDL to use. This is usually not a problem in vanilla JSF applications or even vanilla Trinidad applications, but in frameworks (such as Oracle) where the viewId of an included fragment comes into play (iow, the fragment is in context and not the main page), the PageResolver implementation can no longer return the correct physical URI for the logical viewId. It merely returns the logical viewId.
The problem is further exasperated if the logical viewId of the page does not contain an extension. As there is no extension available, the VDL returned is the JspViewHandlingStrategy always. This is disastrous when the page is being rendered using FaceletsVDL.
One way to resolve this issue is to cache the physical URI of the page on the ViewRoot's viewMap and return the cached value whenever the VDLFactory.getVDL() is called for a viewId that matches the current viewRoot's viewId.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1942)
ViewDeclarationLanguageFactoryImpl implementation should cache physical URI
for the current viewId on the ViewMap
Posted by "Max Starets (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922970#action_12922970 ]
Max Starets commented on TRINIDAD-1942:
---------------------------------------
+1 for the patch, but the second FacesContext.getCurrentInstance() lookup in getViewDeclarationLanguage() should be removed.
> ViewDeclarationLanguageFactoryImpl implementation should cache physical URI for the current viewId on the ViewMap
> -----------------------------------------------------------------------------------------------------------------
>
> Key: TRINIDAD-1942
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1942
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
> Affects Versions: 2.0.0-alpha-2
> Reporter: Pavitra Subramaniam
> Attachments: jira-1942.patch
>
>
> In an included page (or fragment) if a composite component gets used, the CompositeComponentTagHandler retrieves the logical viewId (context.getViewRoot().getViewId()) first and then gets its physical URI in order to determine the VDL to use. This is usually not a problem in vanilla JSF applications or even vanilla Trinidad applications, but in frameworks (such as Oracle) where the viewId of an included fragment comes into play (iow, the fragment is in context and not the main page), the PageResolver implementation can no longer return the correct physical URI for the logical viewId. It merely returns the logical viewId.
> The problem is further exasperated if the logical viewId of the page does not contain an extension. As there is no extension available, the VDL returned is the JspViewHandlingStrategy always. This is disastrous when the page is being rendered using FaceletsVDL.
> One way to resolve this issue is to cache the physical URI of the page on the ViewRoot's viewMap and return the cached value whenever the VDLFactory.getVDL() is called for a viewId that matches the current viewRoot's viewId.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1942) ViewDeclarationLanguageFactoryImpl
implementation should cache physical URI for the current viewId on the
ViewMap
Posted by "Max Starets (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Max Starets updated TRINIDAD-1942:
----------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0.3-core
Status: Resolved (was: Patch Available)
> ViewDeclarationLanguageFactoryImpl implementation should cache physical URI for the current viewId on the ViewMap
> -----------------------------------------------------------------------------------------------------------------
>
> Key: TRINIDAD-1942
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1942
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
> Affects Versions: 2.0.0-alpha-2
> Reporter: Pavitra Subramaniam
> Fix For: 2.0.0.3-core
>
> Attachments: jira-1942-II.patch, jira-1942.patch
>
>
> In an included page (or fragment) if a composite component gets used, the CompositeComponentTagHandler retrieves the logical viewId (context.getViewRoot().getViewId()) first and then gets its physical URI in order to determine the VDL to use. This is usually not a problem in vanilla JSF applications or even vanilla Trinidad applications, but in frameworks (such as Oracle) where the viewId of an included fragment comes into play (iow, the fragment is in context and not the main page), the PageResolver implementation can no longer return the correct physical URI for the logical viewId. It merely returns the logical viewId.
> The problem is further exasperated if the logical viewId of the page does not contain an extension. As there is no extension available, the VDL returned is the JspViewHandlingStrategy always. This is disastrous when the page is being rendered using FaceletsVDL.
> One way to resolve this issue is to cache the physical URI of the page on the ViewRoot's viewMap and return the cached value whenever the VDLFactory.getVDL() is called for a viewId that matches the current viewRoot's viewId.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1942) ViewDeclarationLanguageFactoryImpl
implementation should cache physical URI for the current viewId on the
ViewMap
Posted by "Pavitra Subramaniam (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pavitra Subramaniam updated TRINIDAD-1942:
------------------------------------------
Status: Patch Available (was: Open)
> ViewDeclarationLanguageFactoryImpl implementation should cache physical URI for the current viewId on the ViewMap
> -----------------------------------------------------------------------------------------------------------------
>
> Key: TRINIDAD-1942
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1942
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
> Affects Versions: 2.0.0-alpha-2
> Reporter: Pavitra Subramaniam
> Attachments: jira-1942.patch
>
>
> In an included page (or fragment) if a composite component gets used, the CompositeComponentTagHandler retrieves the logical viewId (context.getViewRoot().getViewId()) first and then gets its physical URI in order to determine the VDL to use. This is usually not a problem in vanilla JSF applications or even vanilla Trinidad applications, but in frameworks (such as Oracle) where the viewId of an included fragment comes into play (iow, the fragment is in context and not the main page), the PageResolver implementation can no longer return the correct physical URI for the logical viewId. It merely returns the logical viewId.
> The problem is further exasperated if the logical viewId of the page does not contain an extension. As there is no extension available, the VDL returned is the JspViewHandlingStrategy always. This is disastrous when the page is being rendered using FaceletsVDL.
> One way to resolve this issue is to cache the physical URI of the page on the ViewRoot's viewMap and return the cached value whenever the VDLFactory.getVDL() is called for a viewId that matches the current viewRoot's viewId.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.