I was going by the description of page actions in the seam docs, section 3.1.1
anonymous wrote :
| The page action method can return a JSF outcome. If the outcome is non-null, Seam will delegate to the defined JSF navigation rules and a different view may end up being rendered.
|
I took that to mean that a null outcome meant that it would proceed to the "default" view (the one it would land on without a page action).
At any rate, using the propagation parameter looks like a much cleaner way of doing it than blank page actions (though it's usually not a bad place to stick application-level audit log messages). Thanks for pointing it out (and for putting up with my endless questions). You rock my small self-centered universe :)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979539#3979539
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979539
Aha, that did it, and I get ... yay, an HTTP 500 .. but the right error on the console. I guess dealing gracefully with the exception means catching it in update() and company. Figuring out how to present a UI to merge changes should be an interesting project.
I can't see anything in @Begin's javadoc that tells me about return values, and I assumed page actions had to return either null to proceed to the given view-id, or optionally return a new viewid. Should I should use s:commandLink if I need to defer to a page action instead? I'll eventually move my complex navigation requirements into jbpm, but it's nice to be able to hack it out with actions first.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979536#3979536
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979536