[
http://jira.jboss.com/jira/browse/JBSEAM-1296?page=comments#action_12414988 ]
Vladimir Kovalyuk commented on JBSEAM-1296:
-------------------------------------------
I completely agree with Chris. I voted for this issue because I'm not able to use
rich:menuItem in the main menu (with reasonable effort). The reason is that Seam
propagates long-running conversation when redirecting to the page that doesn't suppose
to be in long-running context. Chris' suggestion would help.
I believe any library and framework should be complete. Providing jsf component attribute,
jsf tag and Redirect method Seam should go ahead and provide support in pages.xml in order
to eliminate the gap and make the framework complete.
Add <propagation type=""/> element to
<redirect/> / <render/> in pages.xml
--------------------------------------------------------------------------
Key: JBSEAM-1296
URL:
http://jira.jboss.com/jira/browse/JBSEAM-1296
Project: Seam
Issue Type: Feature Request
Components: Core
Affects Versions: 1.2.1.GA, 1.2.0.GA
Reporter: Chris Rudd
While you can add a the propagation via a parameter its a bit verbose and cluttered (due
to the value binding string literal)
<page view-id="/editDocument.xhtml">
<navigation from-action="#{documentEditor.update}">
<rule if="#{documentEditor.errors.empty}">
<end-conversation/>
<redirect view-id="/viewDocument.xhtml">
<param name="conversationPropagation"
value="#{'none'}"/>
</redirect>
</rule>
</navigation>
</page>
Adding a <propagation type="?"/> would be much clearer.
<page view-id="/editDocument.xhtml">
<navigation>
<rule if-outcome="done">
<end-conversation/>
<redirect view-id="/viewDocument.xhtml">
<propagation type="none"/>
</redirect>
</rule>
</navigation>
</page>
Side note :
The reason for needing to control the propagation in the circumstance above is so that
the target view (/viewDocument.xhtml) can start with a new clean conversation. The
redirect mechanism delays the end of the conversation untill it gets to the redirected to
view, but I dont want that conv to be used. The before-redirect attribute doesnt work in
this case as the redirect url needs to include data from the existing conversation (page
parameters). I use the same scenario in other places via s:link/s:button but I cannot do
this here as its dependent on the outcome not what link/button I pressed
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira