[ http://jira.jboss.com/jira/browse/JBSEAM-2469?page=all ] Norman Richards updated JBSEAM-2469: ------------------------------------ Fix Version/s: 2.1.0.GA (was: 2.1.0.A1) -- 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

[ http://jira.jboss.com/jira/browse/JBSEAM-2469?page=all ] Pete Muir updated JBSEAM-2469: ------------------------------ Fix Version/s: 2.1.0.GA (was: 2.1.0.BETA1) -- 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

[ http://jira.jboss.com/jira/browse/JBSEAM-2469?page=comments#action_12414169 ] Stephen Friedrich commented on JBSEAM-2469: ------------------------------------------- Hm, many of my pages are reachable both through get (search results links) and through postbacks (navigating through a hierarchy). I need to to implement both ways: The first for bookmarkable links (or links from other places at our intranet to specific products in my catalog app), the latter for usability and performance (using ajax to update only relevant parts when for example a dropdown value is changed). It seems to me that what this request really aims at, is to have the page action triggered only once for the page. Rather than having a special "postback" flag, could we have a mechanism instead that automatically sets a flag in page context to indicate that the page action already has been executed once, and check that if the option is true at the page action? -- 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

[ http://jira.jboss.com/jira/browse/JBSEAM-2469?page=comments#action_12414234 ] Dan Allen commented on JBSEAM-2469: ----------------------------------- I'm not sure if I can make this explanation make sense, but what you are proposing is exactly what I have proposed. Here goes. The very presence of the javax.faces.ViewState param in the request identifies it as a postback (the UI component tree is restored). There is no need storing a flag in the page context since we already know it is a postback then for that page. If you disable the page action on postback, as I am proposing, then it would be impossible for the page action to execute twice as long as you continue to postback to the same page (perform any sort of JSF action on the page). Now, if you were to navigate after a postback, either to the same page (redirect) or another page, then it ceases to be classified as a postback at that point. Thus, the page action will once again be executed for whatever page you are navigating to, again the behavior you desire. Trust that what you are asking for is what we plan to implement. Now, if you want to disable the page action even on a followup initial request (let's say as part of the same conversation), then you have to do using your own business logic combined with the "if" attribute on the <action> element. -- 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

[ http://jira.jboss.com/jira/browse/JBSEAM-2469?page=comments#action_12414252 ] Dan Allen commented on JBSEAM-2469: ----------------------------------- Ah, I need to clarify a bit because I see that if I am getting my facts mixed up. #1) If your navigation rule uses <render> and that view ID is different than the current view ID, then a new UI component tree is created. That clears any prior page context variables. However, page actions are *not* executed in this case (because it is not a top-level request). Page actions are only executed on a new request (regardless of it being a GET or POST). #2) If your navigation rule uses <redirect>, regardless of whether the view ID is the same or different, a new request is issued. As a result, a new UI component tree is created, any prior page context variables are cleared out, and page actions *do* execute. Unfortunately, there is no way to know (short of using request parameters) that this request (after the redirect) has any relation to a postback. (Ah, except the temporary conversation, which does survive the redirect. So perhaps you could stuff something into the conversation scope). So if you are always using <redirect>, then yes, your page actions are going to be invoked even if you have the postback disabled flag (which is not yet developed). I'm not sure you are going to get support from Seam here. You need to make your page actions aware of this situation. My suggestion is to outject something to the conversation scope and then check for it in your page action. Conversations (even if they are temporary) do survive the redirect. You can check for a temporary conversation by using #{manager.currentConversationEntry.removeAfterRedirect} -- 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

[ http://jira.jboss.com/jira/browse/JBSEAM-2469?page=comments#action_12414260 ] Stephen Friedrich commented on JBSEAM-2469: ------------------------------------------- Thanks again for the explanation and your patience. I think it would really be a better solution to utilize Seam's capability of having state surviving a redirect. After all that is what seam also does for FacesMessages, right? If this is implemented in the easy way, by making it dependent on the postback/initial request distinction it would be the source of confusion and potential bugs. You would have to be much more familiar with technical details to see when the option might be useful. Also I think redirect-after-post is a common idiom, so even if you know about these technical details, you will simply not be able to use the solution. -- 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

[ http://jira.jboss.com/jira/browse/JBSEAM-2469?page=comments#action_12414829 ] Dan Allen commented on JBSEAM-2469: ----------------------------------- I'm willing to say that if a postback leads to rendering the same page, even if a <redirect> is used, then the page action for that page is disabled. I would need a vote on that though. -- 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

[ https://jira.jboss.org/jira/browse/JBSEAM-2469?page=com.atlassian.jira.pl... ] Demetrio Filocamo commented on JBSEAM-2469: ------------------------------------------- I saw you moved the issue to "The future", I think it is a very important issue because it's annoying (and causes a lot of problems if you don't know it) to mind that page actions are called on every ajax request... If it is not so complex why did you move? Demetrio Filocamo -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-2469?page=com.atlassian.jira.pl... ] Dan Allen updated JBSEAM-2469: ------------------------------ Fix Version/s: 2.1.0.GA -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-2469?page=com.atlassian.jira.pl... ] Pete Muir updated JBSEAM-2469: ------------------------------ Fix Version/s: 2.1.0.CR1 (was: 2.1.0.GA) Sure. But it must be by CR1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-2469?page=com.atlassian.jira.pl... ] Dan Allen resolved JBSEAM-2469. ------------------------------- Fix Version/s: 2.0.3.CR2 Resolution: Done Labels: page-action postback (was: ) I decided to keep the implementation simple by giving the developer a flag to disable the page action during a standard JSF postback. The spirit of page actions from day 1 was to provide a way to execute an action on an initial GET request. Typically, you don't need this behavior during a postback because you have at least a dozen other ways to perform work (and lots of information to do it with). To maintain backwards compatibility (and generally just be polite), page actions will execute on any request by default. If you want to disable the action during a JSF postback, you would define the action as follows: <execute action="#{componentName.prepareData}" on-postback="false"/> For those of you that requested more features, I want to remind you that the "if" attribute gives you tremendous flexibility. And you can set any context variable you want during a page action which you can then reference to disable it on a subsequent request if the basic use case here doesn't fit your needs. We cannot design the framework to fill individual needs or else it would become a tangled ball of mess. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira