[jbossseam-issues] [JBoss JIRA] Closed: (JBSEAM-1300) AJAX4JSF call/partial view rerender from a view triggers the Seam page action for the view

AJAX4JSF call/partial view rerender from a view triggers the Seam page action for the view ------------------------------------------------------------------------------------------ Key: JBSEAM-1300 URL: http://jira.jboss.com/jira/browse/JBSEAM-1300 Project: JBoss Seam Issue Type: Bug Affects Versions: 1.2.0.GA Reporter: John Chesher I reused the AJAX4JSF search page/code from the booking example to build a search page for my application. I decided to make the search EJB session-scoped, so that my search criteria would still be there anytime I came back to the screen. I also wanted to display the "previous" search results whenever I came back to that page, but I wanted to perform a new search, just in case the results would be different searching with the same criteria, but at this new point in time. So, I added a page action in pages.xml. Everything seemed to work fine, but I noticed that whenever I do an AJAX-based search from the screen, it does the search twice, once for the AJAX call and apparently once again for the page action defined in pages.xml. I hadn't thought about it, but a coworker suggested that was behavior he was not expecting, as he thought the AJAX call would be a get rather than a post and that, since the entire page is not rerendered (we tested and it's not), Seam would not execute the page action specified in pages.xml. I implemented a "workaround" by having my AJAX call invoke a dummy method (does almost nothing), then letting the method specified on the page action do the real work of the search. This seems to provide the functionality I want without doing a redundant search when doing the AJAX-driven search, but we felt this was a pretty odd way to have to implement this functionality. Code snippets are below. Am I missing something? Is there a more "correct"/elegant way to implement the desired functionality when using Seam and AJAX4JSF together? The less-than-elegant solution I have now works, but I want to ensure I haven't leveraged unintended functionality, which could yield unexpected results or could be disallowed in a future release, or something like that.