my initial thought would be that there was some other, more specific
navigation-case that triggered instead (more specific = from-action +
from-outcome, as opposed to just having a from-outcome). however, i've
looked at the navigation rules myself, and that doesn't appear to be the
case.
i know of no reason why that should fail. going to fire up an instance
and take a look at that use case now.
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