ok, so it turns out this is the standard error handling mechanism for
JSF. if there is some error during the JSF lifecycle, the default
navigation handler will *forward* back to the same page you came from.
in this case, you get punted back to "create.xhtml". and, since we're
dealing with forwards, you lose your "state", namely the id parameter.
so, if you want the navigation rule to work, the JSF lifecycle needs to
NOT be interrupted. gotta fix whatever error is happening after you
click cancel.
John Mazzitelli wrote:
If you go to:
http://localhost:7080/rhq/resource/content/create.xhtml?id=500551
(where 500551 represents a JBossAS resource in my inventory)
and you click cancel, the browser is redirected to this URL:
http://localhost:7080/rhq/resource/content/create.xhtml
and the page that gets rendered is a generic JSF error page.
Here's the thing I don't get. The navigation rules say that upon
cancel, this should go to the deploy.xhtml (with an id param), NOT
create.xhtml:
<navigation-rule>
<from-view-id>/rhq/resource/content/create.xhtml</from-view-id>
<navigation-case>
<from-action>#{CreateNewPackageUIBean.createPackage}</from-action>
<from-outcome>success</from-outcome>
<to-view-id>/rhq/resource/content/confirm-create.xhtml</to-view-id>
</navigation-case>
<navigation-case>
<from-outcome>cancel</from-outcome>
<to-view-id>/rhq/resource/content/deploy.xhtml?id=#{param.id}</to-view-id>
<redirect/>
</navigation-case> </navigation-rule>
Why is it going to create.xhtml???? Notice it goes there WITHOUT an
"id" parameter, and hence why I think this error is happening.
Something isn't right with our navigation rules now - but obviously,
this USED to work. I'm wondering if Seam created a problem here??
_______________________________________________
jopr-dev mailing list
jopr-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jopr-dev