[
http://issues.apache.org/struts/browse/SHALE-316?page=comments#action_38470 ]
Gary VanMatre commented on SHALE-316:
-------------------------------------
Tom, I was able to recreate the problem. The reason why one layout works over
the other has to do with where the dynamic part of the tree is located. The
layout that works places the navigation panel before the variable body. The
layout that doesn't work places the variable body content before the navigation.
One works over the other because of how the HtmlPanelNavigationMenu works. On
the decode of this component, it saves the current view root in the request.
The next view is created or restored and the rendering invoked on the
HtmlPanelNavigationMenu. The previous view root is pulled from request scope.
The logic looks to see if it can find the current component by client id in the
previous view root. This fails because the dynamic content is before the
navigation.
The Clay component is a NamingContainer. The layers of template inclusion are
handled in a Clay full view by nesting the Clay component as a child of itself.
This is why the client id's are so deep when using the full XML or HTML views.
This is not really a Clay issue but more of an issue of the strategy that the
HtmlPanelNavigationMenu component uses to determine the previous state.
org.apache.myfaces.custom.navmenu.htmlnavmenu.HtmlPanelNavigationMenu:
public void encodeBegin(FacesContext context) throws IOException {
...
...
...
UIViewRoot previousRoot =
(UIViewRoot)context.getExternalContext().getRequestMap().get(PREVIOUS_VIEW_ROOT);
if (previousRoot != null) {
if (previousRoot.findComponent(getClientId(context)) instanceof
HtmlPanelNavigationMenu) {
restoreOpenActiveStates(context, previousRoot,
getChildren());
}
}
When used in JSP, the naming containers are more controlled but I think we
could break this component in JSP by adding a subview to one of the templates.
<f:subview id="bpage2">
<jsp:include page="/no_clay/bmenu.jsp" />
</f:subview>
I think this component would be better off it required id's for the
commandNavigation2 components. It could the recursively search the previous
tree for a component with a matching id (not clientId).
If you are ok with this response, please change the status to resolved. I did
fix the other issue with the header template. The second fix that really
cleaned up that namespace verbatim was on 10/21.
This is a great example. Would you consider cleaning it up and submitting it
as an addition to the shale-apps?
> tomahawk's panelNavigation2 doesn't keep state when navigating between views
> ----------------------------------------------------------------------------
>
> Key: SHALE-316
> URL: http://issues.apache.org/struts/browse/SHALE-316
> Project: Shale
> Issue Type: Bug
> Components: Clay
> Affects Versions: 1.0.0, 1.0.1, 1.0.2, 1.0.4-SNAPSHOT, 1.0.3
> Environment: tomcat 5.5.17, myfaces 1.1.4, tomahawk 1.1.3, shale
> 1.0.4-SNAPSHOT
> Reporter: Tom Pasierb
> Assigned To: Gary VanMatre
> Attachments: clayTests-2.zip, clayTests.zip
>
>
> I prepared an example which is attached to the issue entry. Use maven to
> build the war or exploded app directory and run it. It should start fine. I
> described briefly what goes wrong and what causes it in my opinion.
> Basically clay behaves differently if the order in which the panelNavigation2
> and symbols are placed in the template file changes. This probably doesn't
> explain much - just look at the example.
> I hope that the example I provided will be enough to correct the problem ;-)
> Regards,
--
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
