Re: [Trinidad 2] AJAX branch ready for testing
On Tue, Apr 20, 2010 at 6:40 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: On Tue, Apr 20, 2010 at 7:59 AM, Matthias Wessendorf mat...@apache.org wrote: on the pprDemos.jspx stuff, there is a bunch of tests for PPR, one of the has the header Command components with partialSubmit, which does not work (in the trinidad demo) Works fine for me using -Djsf=ri2 except for the selectManyListbox once I did a rebuild and refresh. Thanks for the pointer on the old ri2/myfaces2 profiles. I just removed them, since the ri/myfaces profiles were already pointing to JSF2, so these are no longer needed (have been introduced as a tmp thing, when the JSF2 work started) -Matthias File (in SVN) is located there: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3/trinidad-examples/trinidad-demo/src/main/webapp/demos/pprDemos.jspx On Tue, Apr 20, 2010 at 6:37 AM, Max Starets max.star...@oracle.com wrote: Matthias, What do you mean when you say 'command components with partialSubmit do not work'? Thanks, Max On Apr 20, 2010, at 3:26 AM, Matthias Wessendorf mat...@apache.org wrote: Checked Mojarra 2.0.1 and MyFaces 2.0.0 (out soon) - both have the NPE filed in TRINIDAD-1786 * Mojarra: -PPR on select* works (exception see above) - Command components with partialSubmit does _not_ work * MyFaces: - all PPR stuff does a full page-refresh I am fine in merging these bits to trunk, but before we acutally do a release, we should check what's going wrong in MyFaces/Trinidad ;-) (I think it must be an issue in MyFaces, so once I have some more time, I will file a bug against that, with a little better description) -Matthias On Tue, Apr 20, 2010 at 9:09 AM, Matthias Wessendorf mat...@apache.org wrote: Ok, looks like you are talking about JSF2's JS/Ajax stuff. The term mojarra is slightly confusing, since I understand it as a specific dependency to that particular implementation. But looks like we do not have that, for the ajax stuff, which is great. -Matthias On Tue, Apr 20, 2010 at 9:05 AM, Matthias Wessendorf mat...@apache.org wrote: On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Starets max.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter:
Re: [Trinidad 2] AJAX branch ready for testing
Yes, the -Djsf=ri profile works (with the know exception), but default profile (with temporary using MyFaces 2.0.1-SNAPSHOT), I do get a full-page-refresh. See MYFACES-2666 -Matthias On Tue, Apr 20, 2010 at 6:40 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: On Tue, Apr 20, 2010 at 7:59 AM, Matthias Wessendorf mat...@apache.org wrote: on the pprDemos.jspx stuff, there is a bunch of tests for PPR, one of the has the header Command components with partialSubmit, which does not work (in the trinidad demo) Works fine for me using -Djsf=ri2 except for the selectManyListbox once I did a rebuild and refresh. File (in SVN) is located there: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3/trinidad-examples/trinidad-demo/src/main/webapp/demos/pprDemos.jspx On Tue, Apr 20, 2010 at 6:37 AM, Max Starets max.star...@oracle.com wrote: Matthias, What do you mean when you say 'command components with partialSubmit do not work'? Thanks, Max On Apr 20, 2010, at 3:26 AM, Matthias Wessendorf mat...@apache.org wrote: Checked Mojarra 2.0.1 and MyFaces 2.0.0 (out soon) - both have the NPE filed in TRINIDAD-1786 * Mojarra: -PPR on select* works (exception see above) - Command components with partialSubmit does _not_ work * MyFaces: - all PPR stuff does a full page-refresh I am fine in merging these bits to trunk, but before we acutally do a release, we should check what's going wrong in MyFaces/Trinidad ;-) (I think it must be an issue in MyFaces, so once I have some more time, I will file a bug against that, with a little better description) -Matthias On Tue, Apr 20, 2010 at 9:09 AM, Matthias Wessendorf mat...@apache.org wrote: Ok, looks like you are talking about JSF2's JS/Ajax stuff. The term mojarra is slightly confusing, since I understand it as a specific dependency to that particular implementation. But looks like we do not have that, for the ajax stuff, which is great. -Matthias On Tue, Apr 20, 2010 at 9:05 AM, Matthias Wessendorf mat...@apache.org wrote: On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Starets max.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog:
Re: [Trinidad 2] AJAX branch ready for testing
can you file a jira issue ? On Mon, Apr 19, 2010 at 7:37 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: _ajaxOldDomElements is code in Page.js, this looks like a bug in Trinidad that needs to be fixed On Fri, Apr 9, 2010 at 8:52 AM, Matthias Wessendorf mat...@apache.org wrote: looks like the 2.0.1 are just labeled as Mojarra 2.0.2 (SNAPSHOT 20091204) I now updated the pom to 2.0.2 and got this log: INFO: Initializing Mojarra 2.0.2 (FCS b10) But the error is the same on the clientBehaviorHolder.xhtml page -Matthias On Fri, Apr 9, 2010 at 4:33 PM, Matthias Wessendorf mat...@apache.org wrote: eh, funny. the pom is actually configured with 2.0.1. Something is going wrong here :-) On Fri, Apr 9, 2010 at 4:15 PM, Max Starets max.star...@oracle.com wrote: Matthias, Are you getting the same results with Mojarra 2.0.1? Max Matthias Wessendorf wrote: hi, I gave it a quick try. Here are my results: Page: http://localhost:8080/trinidad-demo/faces/demos/clientBehaviorHolder.xhtml JSF_RI (Mojarra 2.0.2 (SNAPSHOT 20091204)) results: I entered some text and clicked submit via JSF Ajax Got this (in an alert JS box): httpError: The Http Transport returned a 0 status code. This is usually the result of mixing ajax and full requests. This is usually undesired, for both performance and data integrity reasons. second click on the same button I got this JS error. mojarra is not defined [Break on this error] var func = new Function(event, handler); === the submit button works. MyFaces 2.0.0-SNAPHOT results: (using snapshot since the ViewExpiredException is gone in latest snapshot ) * submit button gives me this ALERT() box: TypeError: this._ajaxOldDomElements is null followed by this: malformedXML-- * Submit via JSF Ajax: I get this alert() BOX: httpError-httpError-Request failed Are there any other pages where I can test the new functionality ? -Matthias On Wed, Apr 7, 2010 at 4:33 PM, Max Starets max.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad 2] AJAX branch ready for testing
On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Starets max.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad 2] AJAX branch ready for testing
Ok, looks like you are talking about JSF2's JS/Ajax stuff. The term mojarra is slightly confusing, since I understand it as a specific dependency to that particular implementation. But looks like we do not have that, for the ajax stuff, which is great. -Matthias On Tue, Apr 20, 2010 at 9:05 AM, Matthias Wessendorf mat...@apache.org wrote: On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Starets max.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad 2] AJAX branch ready for testing
Checked Mojarra 2.0.1 and MyFaces 2.0.0 (out soon) - both have the NPE filed in TRINIDAD-1786 * Mojarra: -PPR on select* works (exception see above) - Command components with partialSubmit does _not_ work * MyFaces: - all PPR stuff does a full page-refresh I am fine in merging these bits to trunk, but before we acutally do a release, we should check what's going wrong in MyFaces/Trinidad ;-) (I think it must be an issue in MyFaces, so once I have some more time, I will file a bug against that, with a little better description) -Matthias On Tue, Apr 20, 2010 at 9:09 AM, Matthias Wessendorf mat...@apache.org wrote: Ok, looks like you are talking about JSF2's JS/Ajax stuff. The term mojarra is slightly confusing, since I understand it as a specific dependency to that particular implementation. But looks like we do not have that, for the ajax stuff, which is great. -Matthias On Tue, Apr 20, 2010 at 9:05 AM, Matthias Wessendorf mat...@apache.org wrote: On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Starets max.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad 2] AJAX branch ready for testing
Btw. thanks guys for the effort, I think the tests also were a good indicator about the state of our javascripts. Which looked quite good btw. The main issues I have seen so far were on the spec level. We really need a queue control mechanism on the spec level and a timeout as well, hanging xhr cores should be terminated within an adjustable timeframe, and a load of inputs should not fill up the queue. Most of this is resolvable one way or the other outside, but it needs to be addressed on spec level. Werner Am 19.04.10 23:58, schrieb Andrew Robinson: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Staretsmax.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew
Re: [Trinidad 2] AJAX branch ready for testing
Sorry - all PPR stuff does a full page-refresh wasn´t that a caching issue on the browsers side, because I was investigating that problem and could not reproduce it. Werner Am 20.04.10 09:26, schrieb Matthias Wessendorf: Checked Mojarra 2.0.1 and MyFaces 2.0.0 (out soon) - both have the NPE filed in TRINIDAD-1786 * Mojarra: -PPR on select* works (exception see above) - Command components with partialSubmit does _not_ work * MyFaces: - all PPR stuff does a full page-refresh I am fine in merging these bits to trunk, but before we acutally do a release, we should check what's going wrong in MyFaces/Trinidad ;-) (I think it must be an issue in MyFaces, so once I have some more time, I will file a bug against that, with a little better description) -Matthias On Tue, Apr 20, 2010 at 9:09 AM, Matthias Wessendorfmat...@apache.org wrote: Ok, looks like you are talking about JSF2's JS/Ajax stuff. The term mojarra is slightly confusing, since I understand it as a specific dependency to that particular implementation. But looks like we do not have that, for the ajax stuff, which is great. -Matthias On Tue, Apr 20, 2010 at 9:05 AM, Matthias Wessendorfmat...@apache.org wrote: On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Staretsmax.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad 2] AJAX branch ready for testing
Matthias, What do you mean when you say 'command components with partialSubmit do not work'? Thanks, Max On Apr 20, 2010, at 3:26 AM, Matthias Wessendorf mat...@apache.org wrote: Checked Mojarra 2.0.1 and MyFaces 2.0.0 (out soon) - both have the NPE filed in TRINIDAD-1786 * Mojarra: -PPR on select* works (exception see above) - Command components with partialSubmit does _not_ work * MyFaces: - all PPR stuff does a full page-refresh I am fine in merging these bits to trunk, but before we acutally do a release, we should check what's going wrong in MyFaces/ Trinidad ;-) (I think it must be an issue in MyFaces, so once I have some more time, I will file a bug against that, with a little better description) -Matthias On Tue, Apr 20, 2010 at 9:09 AM, Matthias Wessendorf mat...@apache.org wrote: Ok, looks like you are talking about JSF2's JS/Ajax stuff. The term mojarra is slightly confusing, since I understand it as a specific dependency to that particular implementation. But looks like we do not have that, for the ajax stuff, which is great. -Matthias On Tue, Apr 20, 2010 at 9:05 AM, Matthias Wessendorf mat...@apache.org wrote: On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Starets max.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad 2] AJAX branch ready for testing
on the pprDemos.jspx stuff, there is a bunch of tests for PPR, one of the has the header Command components with partialSubmit, which does not work (in the trinidad demo) File (in SVN) is located there: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3/trinidad-examples/trinidad-demo/src/main/webapp/demos/pprDemos.jspx On Tue, Apr 20, 2010 at 6:37 AM, Max Starets max.star...@oracle.com wrote: Matthias, What do you mean when you say 'command components with partialSubmit do not work'? Thanks, Max On Apr 20, 2010, at 3:26 AM, Matthias Wessendorf mat...@apache.org wrote: Checked Mojarra 2.0.1 and MyFaces 2.0.0 (out soon) - both have the NPE filed in TRINIDAD-1786 * Mojarra: -PPR on select* works (exception see above) - Command components with partialSubmit does _not_ work * MyFaces: - all PPR stuff does a full page-refresh I am fine in merging these bits to trunk, but before we acutally do a release, we should check what's going wrong in MyFaces/Trinidad ;-) (I think it must be an issue in MyFaces, so once I have some more time, I will file a bug against that, with a little better description) -Matthias On Tue, Apr 20, 2010 at 9:09 AM, Matthias Wessendorf mat...@apache.org wrote: Ok, looks like you are talking about JSF2's JS/Ajax stuff. The term mojarra is slightly confusing, since I understand it as a specific dependency to that particular implementation. But looks like we do not have that, for the ajax stuff, which is great. -Matthias On Tue, Apr 20, 2010 at 9:05 AM, Matthias Wessendorf mat...@apache.org wrote: On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Starets max.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad 2] AJAX branch ready for testing
Also, are you using JSF RI? MyFaces is known to be bad with Ajax. On 04/20/2010 08:50 AM, Max Starets wrote: Hey Matthias, This works for me: http://adc2100180.us.oracle.com:7101/trinidad-demo-context-root/faces/demos/pprDemos.jspx Are you seeing any errors? Is request showing up in Firebug console? Thanks, Max Matthias Wessendorf wrote: on the pprDemos.jspx stuff, there is a bunch of tests for PPR, one of the has the header Command components with partialSubmit, which does not work (in the trinidad demo) File (in SVN) is located there: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3/trinidad-examples/trinidad-demo/src/main/webapp/demos/pprDemos.jspx On Tue, Apr 20, 2010 at 6:37 AM, Max Staretsmax.star...@oracle.com wrote: Matthias, What do you mean when you say 'command components with partialSubmit do not work'? Thanks, Max On Apr 20, 2010, at 3:26 AM, Matthias Wessendorfmat...@apache.org wrote: Checked Mojarra 2.0.1 and MyFaces 2.0.0 (out soon) - both have the NPE filed in TRINIDAD-1786 * Mojarra: -PPR on select* works (exception see above) - Command components with partialSubmit does _not_ work * MyFaces: - all PPR stuff does a full page-refresh I am fine in merging these bits to trunk, but before we acutally do a release, we should check what's going wrong in MyFaces/Trinidad ;-) (I think it must be an issue in MyFaces, so once I have some more time, I will file a bug against that, with a little better description) -Matthias On Tue, Apr 20, 2010 at 9:09 AM, Matthias Wessendorfmat...@apache.org wrote: Ok, looks like you are talking about JSF2's JS/Ajax stuff. The term mojarra is slightly confusing, since I understand it as a specific dependency to that particular implementation. But looks like we do not have that, for the ajax stuff, which is great. -Matthias On Tue, Apr 20, 2010 at 9:05 AM, Matthias Wessendorfmat...@apache.org wrote: On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Staretsmax.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog:http://matthiaswessendorf.wordpress.com/ sessions:http://www.slideshare.net/mwessendorf twitter:http://twitter.com/mwessendorf -- Matthias Wessendorf blog:http://matthiaswessendorf.wordpress.com/ sessions:http://www.slideshare.net/mwessendorf twitter:http://twitter.com/mwessendorf -- Matthias Wessendorf blog:http://matthiaswessendorf.wordpress.com/ sessions:http://www.slideshare.net/mwessendorf twitter:http://twitter.com/mwessendorf -- Andrew Robinson | Principal Software Engineer Phone: +1 303 334 5027 Oracle
Re: [Trinidad 2] AJAX branch ready for testing
Am 20.04.10 17:00, schrieb Andrew Robinson:
Also, are you using JSF RI? MyFaces is known to be bad with Ajax.
Ouch that hit me personally, because I and others spent a load of hours
to make
the our javascripts as good as possible as the spec allowed (with the
help of some others).
Actually if you have run into any errors or problems regarding the Ajax
part (which caused your conclusion), please post them to the jira under
our impl section, so that we can fix it :-), just saying bad with ajax
is no help here :-), we would like to have the best ajax implementation
of both implementations (better than the RI, so any bugreport is
welcome). But no offence taken, back to the topic.
But back to the original problem, the first link (Go to Trinidad demos
home page.) issue following xhr post:
Tr-PPR-Message true
_noJavaScript false
event autosub
itxtChange this text
j_id1078059021_4041e82d
javax.faces.ViewState !h19u5lcmm
javax.faces.ViewState !h19u5lcmm
javax.faces.partial.ajaxtrue
javax.faces.partial.event click
javax.faces.partial.execu...null
javax.faces.source null
org.apache.myfaces.trinid...j_id1078059021_4041e08f
partial true
selOne 0
source j_id1078059021_4041e6c3
and the response is following:
?xml version=1.0 ?
partial-responsechangesupdate
id=tr_j_id1078059021_4041e08f_Postscript![CDATA[span
id=tr_j_id1078059021_4041e08f_Postscriptinput type=hidden
name=sourcescript
type=text/javascriptTrPage.getInstance()._addResetFields('j_id1078059021_4041e08f',[source]);/scriptscript
type=text/javascriptvar
j_id1078059021_4041e08f_SF={};/script/span]]/updateupdate
id=javax.faces.ViewState![CDATA[!h19u5lcmm]]/updateeval![CDATA[TrPage.getInstance().__handlePprResponseAction('/trinidad-demo/faces/demos/pprDemos.jspx');]]/eval/changes/partial-response
Not sure what the eval
TrPage.getInstance().__handlePprResponseAction('/trinidad-demo/faces/demos/pprDemos.jspx');
in this case triggers, it should trigger a go to the homepage.
Werner
Re: [Trinidad 2] AJAX branch ready for testing
Ok I did a testing on the RI the links do not work as well, but wont
even go into the xhr part (I will add a fix here to be coherent to the
RI in our scripts)
what happens is that the links trigger an error
jsf.ajax.request: source not set
throw new Error(jsf.ajax.request: source not set);
Due to a missing source element on trinidads side
(I am more lenient regarding the source, because I also handle detached
objects which some frameworks like dojo or jquery can produce,
but I obviously missed the case of source being null or undefined,
having to throw an explicit error, which is not directly in the spec
afair, but nevertheless I will change that tomorrow if the spec does not
state otherwise)
the original request as posted below
issues:
javax.faces.source null
in our case it just performs an empty roundtrip in case of the ri it
bombs out due to constraints on the javascripts side.
Werner
Am 20.04.10 17:37, schrieb Werner Punz:
Am 20.04.10 17:00, schrieb Andrew Robinson:
Also, are you using JSF RI? MyFaces is known to be bad with Ajax.
Ouch that hit me personally, because I and others spent a load of hours
to make
the our javascripts as good as possible as the spec allowed (with the
help of some others).
Actually if you have run into any errors or problems regarding the Ajax
part (which caused your conclusion), please post them to the jira under
our impl section, so that we can fix it :-), just saying bad with ajax
is no help here :-), we would like to have the best ajax implementation
of both implementations (better than the RI, so any bugreport is
welcome). But no offence taken, back to the topic.
But back to the original problem, the first link (Go to Trinidad demos
home page.) issue following xhr post:
Tr-PPR-Message true
_noJavaScript false
event autosub
itxt Change this text
j_id1078059021_4041e82d
javax.faces.ViewState !h19u5lcmm
javax.faces.ViewState !h19u5lcmm
javax.faces.partial.ajax true
javax.faces.partial.event click
javax.faces.partial.execu... null
javax.faces.source null
org.apache.myfaces.trinid... j_id1078059021_4041e08f
partial true
selOne 0
source j_id1078059021_4041e6c3
and the response is following:
?xml version=1.0 ?
partial-responsechangesupdate
id=tr_j_id1078059021_4041e08f_Postscript![CDATA[span
id=tr_j_id1078059021_4041e08f_Postscriptinput type=hidden
name=sourcescript
type=text/javascriptTrPage.getInstance()._addResetFields('j_id1078059021_4041e08f',[source]);/scriptscript
type=text/javascriptvar
j_id1078059021_4041e08f_SF={};/script/span]]/updateupdate
id=javax.faces.ViewState![CDATA[!h19u5lcmm]]/updateeval![CDATA[TrPage.getInstance().__handlePprResponseAction('/trinidad-demo/faces/demos/pprDemos.jspx');]]/eval/changes/partial-response
Not sure what the eval
TrPage.getInstance().__handlePprResponseAction('/trinidad-demo/faces/demos/pprDemos.jspx');
in this case triggers, it should trigger a go to the homepage.
Werner
Re: [Trinidad 2] AJAX branch ready for testing
Hello Andrew, on my tryouts I used both, see here: http://markmail.org/message/onwsrqwfhu7ai67e -Matthias On Tue, Apr 20, 2010 at 5:00 PM, Andrew Robinson andrew.robin...@oracle.com wrote: Also, are you using JSF RI? MyFaces is known to be bad with Ajax. On 04/20/2010 08:50 AM, Max Starets wrote: Hey Matthias, This works for me: http://adc2100180.us.oracle.com:7101/trinidad-demo-context-root/faces/demos/pprDemos.jspx Are you seeing any errors? Is request showing up in Firebug console? Thanks, Max Matthias Wessendorf wrote: on the pprDemos.jspx stuff, there is a bunch of tests for PPR, one of the has the header Command components with partialSubmit, which does not work (in the trinidad demo) File (in SVN) is located there: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3/trinidad-examples/trinidad-demo/src/main/webapp/demos/pprDemos.jspx On Tue, Apr 20, 2010 at 6:37 AM, Max Starets max.star...@oracle.com wrote: Matthias, What do you mean when you say 'command components with partialSubmit do not work'? Thanks, Max On Apr 20, 2010, at 3:26 AM, Matthias Wessendorf mat...@apache.org wrote: Checked Mojarra 2.0.1 and MyFaces 2.0.0 (out soon) - both have the NPE filed in TRINIDAD-1786 * Mojarra: -PPR on select* works (exception see above) - Command components with partialSubmit does _not_ work * MyFaces: - all PPR stuff does a full page-refresh I am fine in merging these bits to trunk, but before we acutally do a release, we should check what's going wrong in MyFaces/Trinidad ;-) (I think it must be an issue in MyFaces, so once I have some more time, I will file a bug against that, with a little better description) -Matthias On Tue, Apr 20, 2010 at 9:09 AM, Matthias Wessendorf mat...@apache.org wrote: Ok, looks like you are talking about JSF2's JS/Ajax stuff. The term mojarra is slightly confusing, since I understand it as a specific dependency to that particular implementation. But looks like we do not have that, for the ajax stuff, which is great. -Matthias On Tue, Apr 20, 2010 at 9:05 AM, Matthias Wessendorf mat...@apache.org wrote: On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Starets max.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions:
Re: [Trinidad 2] AJAX branch ready for testing
Werner, sorry for the short reply on that email, the tone probably sounded bad. There are state saving problems when using MyFaces. Unfortunately it is bad enough to make it completely non-functional as all PPR post backs fail to restore the state from what I have seen. We have no such errors when using Mojarra. @Matthias or Max: did one of you guys already file a bug on the MyFaces Core for this or do we still need to? To reproduce: 1) Get a working copy of the jsf2_ajax.3 Trinidad Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 2) Run the demo project using Jetty (mvn jetty:run -PjettyConfig) 3) Hit the page: http://localhost:8080/trinidad-demo/faces/demos/ajaxPPRDemos.xhtml 4) Click on one of the buttons at the top (Full Submit button is fine) This error results: SEVERE: An exception occurred javax.faces.application.ViewExpiredException: /demos/ajaxPPRDemos.xhtmlNo saved view state could be found for the view identifier: /demos/ajaxPPRDemos.xhtml at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:114) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:138) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:88) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:247) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:157) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:536) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:930) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:405) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) Form Data sent: itxt1:Change this text2 sf20%3Aitxt2:Change this text2 it1: org.apache.myfaces.trinidad.faces.FORM:j_id933005119_379c87b2 _noJavaScript:false javax.faces.ViewState:!yabr3gltb : javax.faces.behavior.event:action javax.faces.partial.event:click javax.faces.source:axBtn2 javax.faces.partial.ajax:true javax.faces.partial.execute:axBtn2 javax.faces.partial.render:btnTarget Request Headers: Content-Type:application/x-www-form-urlencoded Faces-Request:partial/ajax Origin:http://localhost:8080 Referer:http://localhost:8080/trinidad-demo/faces/demos/ajaxPPRDemos.xhtml User-Agent:Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.9 Safari/533.2 On Tue, Apr 20, 2010 at 9:37 AM, Werner Punz werner.p...@gmail.com wrote: Am 20.04.10 17:00, schrieb Andrew Robinson: Also, are you using JSF RI? MyFaces is known to be bad with Ajax. Ouch that hit me personally, because I and others spent a load of hours to make the our javascripts as good as possible as the spec allowed (with the help of some others). Actually if you have run into any errors or problems regarding the Ajax part (which caused your conclusion), please post them to the jira under our impl section, so that we can fix it :-), just saying bad with ajax is no help here :-), we would like to have the best ajax implementation of both implementations (better than the RI, so any bugreport is welcome). But no offence taken, back to the topic. But back to the original problem, the first link (Go to Trinidad demos home page.) issue following xhr post: Tr-PPR-Message true _noJavaScript false event autosub itxt Change this text
Re: [Trinidad 2] AJAX branch ready for testing
I can see this page failing with JS errors in chrome. I'll have a look On Tue, Apr 20, 2010 at 7:59 AM, Matthias Wessendorf mat...@apache.org wrote: on the pprDemos.jspx stuff, there is a bunch of tests for PPR, one of the has the header Command components with partialSubmit, which does not work (in the trinidad demo) File (in SVN) is located there: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3/trinidad-examples/trinidad-demo/src/main/webapp/demos/pprDemos.jspx On Tue, Apr 20, 2010 at 6:37 AM, Max Starets max.star...@oracle.com wrote: Matthias, What do you mean when you say 'command components with partialSubmit do not work'? Thanks, Max On Apr 20, 2010, at 3:26 AM, Matthias Wessendorf mat...@apache.org wrote: Checked Mojarra 2.0.1 and MyFaces 2.0.0 (out soon) - both have the NPE filed in TRINIDAD-1786 * Mojarra: -PPR on select* works (exception see above) - Command components with partialSubmit does _not_ work * MyFaces: - all PPR stuff does a full page-refresh I am fine in merging these bits to trunk, but before we acutally do a release, we should check what's going wrong in MyFaces/Trinidad ;-) (I think it must be an issue in MyFaces, so once I have some more time, I will file a bug against that, with a little better description) -Matthias On Tue, Apr 20, 2010 at 9:09 AM, Matthias Wessendorf mat...@apache.org wrote: Ok, looks like you are talking about JSF2's JS/Ajax stuff. The term mojarra is slightly confusing, since I understand it as a specific dependency to that particular implementation. But looks like we do not have that, for the ajax stuff, which is great. -Matthias On Tue, Apr 20, 2010 at 9:05 AM, Matthias Wessendorf mat...@apache.org wrote: On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Starets max.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad 2] AJAX branch ready for testing
Hello Andrew, the problem below is already fixed in the up-coming release, which I used to verify this. Let's merge your branch to trunk and work on it to get these other (minor) things fixed. On Tue, Apr 20, 2010 at 6:09 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: Werner, sorry for the short reply on that email, the tone probably sounded bad. There are state saving problems when using MyFaces. Unfortunately it is bad enough to make it completely non-functional as all PPR post backs fail to restore the state from what I have seen. We have no such errors when using Mojarra. @Matthias or Max: did one of you guys already file a bug on the MyFaces Core for this or do we still need to? To reproduce: 1) Get a working copy of the jsf2_ajax.3 Trinidad Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 2) Run the demo project using Jetty (mvn jetty:run -PjettyConfig) 3) Hit the page: http://localhost:8080/trinidad-demo/faces/demos/ajaxPPRDemos.xhtml 4) Click on one of the buttons at the top (Full Submit button is fine) This error results: SEVERE: An exception occurred javax.faces.application.ViewExpiredException: /demos/ajaxPPRDemos.xhtmlNo saved view state could be found for the view identifier: /demos/ajaxPPRDemos.xhtml at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:114) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:138) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:88) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:247) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:157) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:536) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:930) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:405) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) Form Data sent: itxt1:Change this text2 sf20%3Aitxt2:Change this text2 it1: org.apache.myfaces.trinidad.faces.FORM:j_id933005119_379c87b2 _noJavaScript:false javax.faces.ViewState:!yabr3gltb : javax.faces.behavior.event:action javax.faces.partial.event:click javax.faces.source:axBtn2 javax.faces.partial.ajax:true javax.faces.partial.execute:axBtn2 javax.faces.partial.render:btnTarget Request Headers: Content-Type:application/x-www-form-urlencoded Faces-Request:partial/ajax Origin:http://localhost:8080 Referer:http://localhost:8080/trinidad-demo/faces/demos/ajaxPPRDemos.xhtml User-Agent:Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.9 Safari/533.2 On Tue, Apr 20, 2010 at 9:37 AM, Werner Punz werner.p...@gmail.com wrote: Am 20.04.10 17:00, schrieb Andrew Robinson: Also, are you using JSF RI? MyFaces is known to be bad with Ajax. Ouch that hit me personally, because I and others spent a load of hours to make the our javascripts as good as possible as the spec allowed (with the help of some others). Actually if you have run into any errors or problems regarding the Ajax part (which caused your conclusion), please post them to the jira under our impl section, so that we can fix it :-), just saying bad with ajax is no help here :-), we would like to have the best ajax
Re: [Trinidad 2] AJAX branch ready for testing
Hi Andrew, here is the ticket: https://issues.apache.org/jira/browse/MYFACES-2641 Looks like just a ticket for the _ajaxOldDomElements is missing, right ? http://markmail.org/message/tcoi36bneeultdx2 -Matthias On Tue, Apr 20, 2010 at 6:16 PM, Matthias Wessendorf mat...@apache.org wrote: Hello Andrew, the problem below is already fixed in the up-coming release, which I used to verify this. Let's merge your branch to trunk and work on it to get these other (minor) things fixed. On Tue, Apr 20, 2010 at 6:09 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: Werner, sorry for the short reply on that email, the tone probably sounded bad. There are state saving problems when using MyFaces. Unfortunately it is bad enough to make it completely non-functional as all PPR post backs fail to restore the state from what I have seen. We have no such errors when using Mojarra. @Matthias or Max: did one of you guys already file a bug on the MyFaces Core for this or do we still need to? To reproduce: 1) Get a working copy of the jsf2_ajax.3 Trinidad Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 2) Run the demo project using Jetty (mvn jetty:run -PjettyConfig) 3) Hit the page: http://localhost:8080/trinidad-demo/faces/demos/ajaxPPRDemos.xhtml 4) Click on one of the buttons at the top (Full Submit button is fine) This error results: SEVERE: An exception occurred javax.faces.application.ViewExpiredException: /demos/ajaxPPRDemos.xhtmlNo saved view state could be found for the view identifier: /demos/ajaxPPRDemos.xhtml at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:114) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:138) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:88) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:247) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:157) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:536) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:930) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:405) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) Form Data sent: itxt1:Change this text2 sf20%3Aitxt2:Change this text2 it1: org.apache.myfaces.trinidad.faces.FORM:j_id933005119_379c87b2 _noJavaScript:false javax.faces.ViewState:!yabr3gltb : javax.faces.behavior.event:action javax.faces.partial.event:click javax.faces.source:axBtn2 javax.faces.partial.ajax:true javax.faces.partial.execute:axBtn2 javax.faces.partial.render:btnTarget Request Headers: Content-Type:application/x-www-form-urlencoded Faces-Request:partial/ajax Origin:http://localhost:8080 Referer:http://localhost:8080/trinidad-demo/faces/demos/ajaxPPRDemos.xhtml User-Agent:Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.9 Safari/533.2 On Tue, Apr 20, 2010 at 9:37 AM, Werner Punz werner.p...@gmail.com wrote: Am 20.04.10 17:00, schrieb Andrew Robinson: Also, are you using JSF RI? MyFaces is known to be bad with Ajax. Ouch that hit me personally, because I and others spent a load of hours to make the our javascripts as good as possible as the spec allowed (with the help
Re: [Trinidad 2] AJAX branch ready for testing
On Tue, Apr 20, 2010 at 7:59 AM, Matthias Wessendorf mat...@apache.org wrote: on the pprDemos.jspx stuff, there is a bunch of tests for PPR, one of the has the header Command components with partialSubmit, which does not work (in the trinidad demo) Works fine for me using -Djsf=ri2 except for the selectManyListbox once I did a rebuild and refresh. File (in SVN) is located there: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3/trinidad-examples/trinidad-demo/src/main/webapp/demos/pprDemos.jspx On Tue, Apr 20, 2010 at 6:37 AM, Max Starets max.star...@oracle.com wrote: Matthias, What do you mean when you say 'command components with partialSubmit do not work'? Thanks, Max On Apr 20, 2010, at 3:26 AM, Matthias Wessendorf mat...@apache.org wrote: Checked Mojarra 2.0.1 and MyFaces 2.0.0 (out soon) - both have the NPE filed in TRINIDAD-1786 * Mojarra: -PPR on select* works (exception see above) - Command components with partialSubmit does _not_ work * MyFaces: - all PPR stuff does a full page-refresh I am fine in merging these bits to trunk, but before we acutally do a release, we should check what's going wrong in MyFaces/Trinidad ;-) (I think it must be an issue in MyFaces, so once I have some more time, I will file a bug against that, with a little better description) -Matthias On Tue, Apr 20, 2010 at 9:09 AM, Matthias Wessendorf mat...@apache.org wrote: Ok, looks like you are talking about JSF2's JS/Ajax stuff. The term mojarra is slightly confusing, since I understand it as a specific dependency to that particular implementation. But looks like we do not have that, for the ajax stuff, which is great. -Matthias On Tue, Apr 20, 2010 at 9:05 AM, Matthias Wessendorf mat...@apache.org wrote: On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Starets max.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad 2] AJAX branch ready for testing
Actually Command components with partialSubmit works for me on both implementations. What does not work for me on both implementations is Command components with partialSubmit going to another page. Werner Am 20.04.10 18:40, schrieb Andrew Robinson: On Tue, Apr 20, 2010 at 7:59 AM, Matthias Wessendorfmat...@apache.org wrote: on the pprDemos.jspx stuff, there is a bunch of tests for PPR, one of the has the header Command components with partialSubmit, which does not work (in the trinidad demo) Works fine for me using -Djsf=ri2 except for the selectManyListbox once I did a rebuild and refresh. File (in SVN) is located there: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3/trinidad-examples/trinidad-demo/src/main/webapp/demos/pprDemos.jspx On Tue, Apr 20, 2010 at 6:37 AM, Max Staretsmax.star...@oracle.com wrote: Matthias, What do you mean when you say 'command components with partialSubmit do not work'? Thanks, Max On Apr 20, 2010, at 3:26 AM, Matthias Wessendorfmat...@apache.org wrote: Checked Mojarra 2.0.1 and MyFaces 2.0.0 (out soon) - both have the NPE filed in TRINIDAD-1786 * Mojarra: -PPR on select* works (exception see above) - Command components with partialSubmit does _not_ work * MyFaces: - all PPR stuff does a full page-refresh I am fine in merging these bits to trunk, but before we acutally do a release, we should check what's going wrong in MyFaces/Trinidad ;-) (I think it must be an issue in MyFaces, so once I have some more time, I will file a bug against that, with a little better description) -Matthias On Tue, Apr 20, 2010 at 9:09 AM, Matthias Wessendorfmat...@apache.org wrote: Ok, looks like you are talking about JSF2's JS/Ajax stuff. The term mojarra is slightly confusing, since I understand it as a specific dependency to that particular implementation. But looks like we do not have that, for the ajax stuff, which is great. -Matthias On Tue, Apr 20, 2010 at 9:05 AM, Matthias Wessendorfmat...@apache.org wrote: On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Staretsmax.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter:
Re: [Trinidad 2] AJAX branch ready for testing
Werner,
__handlePprResponseAction() is meant to update the action URL on the form
(this is what old Trinidad PPR always did). It's not supposed to do
navigation.
Max
Werner Punz wrote:
Am 20.04.10 17:00, schrieb Andrew Robinson:
Also, are you using JSF RI? MyFaces is known to be bad with Ajax.
Ouch that hit me personally, because I and others spent a load of
hours to make
the our javascripts as good as possible as the spec allowed (with the
help of some others).
Actually if you have run into any errors or problems regarding the
Ajax part (which caused your conclusion), please post them to the jira
under our impl section, so that we can fix it :-), just saying bad
with ajax is no help here :-), we would like to have the best ajax
implementation of both implementations (better than the RI, so any
bugreport is welcome). But no offence taken, back to the topic.
But back to the original problem, the first link (Go to Trinidad demos
home page.) issue following xhr post:
Tr-PPR-Messagetrue
_noJavaScriptfalse
eventautosub
itxtChange this text
j_id1078059021_4041e82d
javax.faces.ViewState!h19u5lcmm
javax.faces.ViewState!h19u5lcmm
javax.faces.partial.ajaxtrue
javax.faces.partial.eventclick
javax.faces.partial.execu...null
javax.faces.sourcenull
org.apache.myfaces.trinid...j_id1078059021_4041e08f
partialtrue
selOne0
sourcej_id1078059021_4041e6c3
and the response is following:
?xml version=1.0 ?
partial-responsechangesupdate
id=tr_j_id1078059021_4041e08f_Postscript![CDATA[span
id=tr_j_id1078059021_4041e08f_Postscriptinput type=hidden
name=sourcescript
type=text/javascriptTrPage.getInstance()._addResetFields('j_id1078059021_4041e08f',[source]);/scriptscript
type=text/javascriptvar
j_id1078059021_4041e08f_SF={};/script/span]]/updateupdate
id=javax.faces.ViewState![CDATA[!h19u5lcmm]]/updateeval![CDATA[TrPage.getInstance().__handlePprResponseAction('/trinidad-demo/faces/demos/pprDemos.jspx');]]/eval/changes/partial-response
Not sure what the eval
TrPage.getInstance().__handlePprResponseAction('/trinidad-demo/faces/demos/pprDemos.jspx');
in this case triggers, it should trigger a go to the homepage.
Werner
Re: [Trinidad 2] AJAX branch ready for testing
Werner, I will look into the navigation issue. The expected behavior with Trinidad in this case is a redirect. Max Werner Punz wrote: Actually Command components with partialSubmit works for me on both implementations. What does not work for me on both implementations is Command components with partialSubmit going to another page. Werner Am 20.04.10 18:40, schrieb Andrew Robinson: On Tue, Apr 20, 2010 at 7:59 AM, Matthias Wessendorfmat...@apache.org wrote: on the pprDemos.jspx stuff, there is a bunch of tests for PPR, one of the has the header Command components with partialSubmit, which does not work (in the trinidad demo) Works fine for me using -Djsf=ri2 except for the selectManyListbox once I did a rebuild and refresh. File (in SVN) is located there: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3/trinidad-examples/trinidad-demo/src/main/webapp/demos/pprDemos.jspx On Tue, Apr 20, 2010 at 6:37 AM, Max Staretsmax.star...@oracle.com wrote: Matthias, What do you mean when you say 'command components with partialSubmit do not work'? Thanks, Max On Apr 20, 2010, at 3:26 AM, Matthias Wessendorfmat...@apache.org wrote: Checked Mojarra 2.0.1 and MyFaces 2.0.0 (out soon) - both have the NPE filed in TRINIDAD-1786 * Mojarra: -PPR on select* works (exception see above) - Command components with partialSubmit does _not_ work * MyFaces: - all PPR stuff does a full page-refresh I am fine in merging these bits to trunk, but before we acutally do a release, we should check what's going wrong in MyFaces/Trinidad ;-) (I think it must be an issue in MyFaces, so once I have some more time, I will file a bug against that, with a little better description) -Matthias On Tue, Apr 20, 2010 at 9:09 AM, Matthias Wessendorfmat...@apache.org wrote: Ok, looks like you are talking about JSF2's JS/Ajax stuff. The term mojarra is slightly confusing, since I understand it as a specific dependency to that particular implementation. But looks like we do not have that, for the ajax stuff, which is great. -Matthias On Tue, Apr 20, 2010 at 9:05 AM, Matthias Wessendorfmat...@apache.org wrote: On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Staretsmax.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter:
Re: [Trinidad 2] AJAX branch ready for testing
Werner, With the latest build, I can see the navigation happening with no issues when you choose Go to Trinidad demos home page on pprDemos.jspx. The response contains the following: ?xml version=1.0 encoding=utf-8? partial-responseredirect url=/trinidad-demo-context-root/faces/index.jspx/redirect/partial-response Max Max Starets wrote: Werner, I will look into the navigation issue. The expected behavior with Trinidad in this case is a redirect. Max Werner Punz wrote: Actually Command components with partialSubmit works for me on both implementations. What does not work for me on both implementations is Command components with partialSubmit going to another page. Werner Am 20.04.10 18:40, schrieb Andrew Robinson: On Tue, Apr 20, 2010 at 7:59 AM, Matthias Wessendorfmat...@apache.org wrote: on the pprDemos.jspx stuff, there is a bunch of tests for PPR, one of the has the header Command components with partialSubmit, which does not work (in the trinidad demo) Works fine for me using -Djsf=ri2 except for the selectManyListbox once I did a rebuild and refresh. File (in SVN) is located there: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3/trinidad-examples/trinidad-demo/src/main/webapp/demos/pprDemos.jspx On Tue, Apr 20, 2010 at 6:37 AM, Max Staretsmax.star...@oracle.com wrote: Matthias, What do you mean when you say 'command components with partialSubmit do not work'? Thanks, Max On Apr 20, 2010, at 3:26 AM, Matthias Wessendorfmat...@apache.org wrote: Checked Mojarra 2.0.1 and MyFaces 2.0.0 (out soon) - both have the NPE filed in TRINIDAD-1786 * Mojarra: -PPR on select* works (exception see above) - Command components with partialSubmit does _not_ work * MyFaces: - all PPR stuff does a full page-refresh I am fine in merging these bits to trunk, but before we acutally do a release, we should check what's going wrong in MyFaces/Trinidad ;-) (I think it must be an issue in MyFaces, so once I have some more time, I will file a bug against that, with a little better description) -Matthias On Tue, Apr 20, 2010 at 9:09 AM, Matthias Wessendorfmat...@apache.org wrote: Ok, looks like you are talking about JSF2's JS/Ajax stuff. The term mojarra is slightly confusing, since I understand it as a specific dependency to that particular implementation. But looks like we do not have that, for the ajax stuff, which is great. -Matthias On Tue, Apr 20, 2010 at 9:05 AM, Matthias Wessendorfmat...@apache.org wrote: On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Staretsmax.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions:
Re: [Trinidad 2] AJAX branch ready for testing
Ajax branch has been merged into the trunk. We'll keep hammering away on the problems that were found (most JSF2, not AJAX related) so we can hopefully stabilize the code for a release in the not too distant future.
Re: [Trinidad 2] AJAX branch ready for testing
Ok then the issue is fixed, the redirect response looks ok to me. I will update tomorrow and will fix the missing no source error on my side so that we get the same behavior on both mojarra and myfaces regarding null sources. Werner Am 20.04.10 20:42, schrieb Max Starets: Werner, With the latest build, I can see the navigation happening with no issues when you choose Go to Trinidad demos home page on pprDemos.jspx. The response contains the following: ?xml version=1.0 encoding=utf-8? partial-responseredirect url=/trinidad-demo-context-root/faces/index.jspx/redirect/partial-response Max Max Starets wrote: Werner, I will look into the navigation issue. The expected behavior with Trinidad in this case is a redirect. Max Werner Punz wrote: Actually Command components with partialSubmit works for me on both implementations. What does not work for me on both implementations is Command components with partialSubmit going to another page. Werner Am 20.04.10 18:40, schrieb Andrew Robinson: On Tue, Apr 20, 2010 at 7:59 AM, Matthias Wessendorfmat...@apache.org wrote: on the pprDemos.jspx stuff, there is a bunch of tests for PPR, one of the has the header Command components with partialSubmit, which does not work (in the trinidad demo) Works fine for me using -Djsf=ri2 except for the selectManyListbox once I did a rebuild and refresh. File (in SVN) is located there: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3/trinidad-examples/trinidad-demo/src/main/webapp/demos/pprDemos.jspx On Tue, Apr 20, 2010 at 6:37 AM, Max Staretsmax.star...@oracle.com wrote: Matthias, What do you mean when you say 'command components with partialSubmit do not work'? Thanks, Max On Apr 20, 2010, at 3:26 AM, Matthias Wessendorfmat...@apache.org wrote: Checked Mojarra 2.0.1 and MyFaces 2.0.0 (out soon) - both have the NPE filed in TRINIDAD-1786 * Mojarra: -PPR on select* works (exception see above) - Command components with partialSubmit does _not_ work * MyFaces: - all PPR stuff does a full page-refresh I am fine in merging these bits to trunk, but before we acutally do a release, we should check what's going wrong in MyFaces/Trinidad ;-) (I think it must be an issue in MyFaces, so once I have some more time, I will file a bug against that, with a little better description) -Matthias On Tue, Apr 20, 2010 at 9:09 AM, Matthias Wessendorfmat...@apache.org wrote: Ok, looks like you are talking about JSF2's JS/Ajax stuff. The term mojarra is slightly confusing, since I understand it as a specific dependency to that particular implementation. But looks like we do not have that, for the ajax stuff, which is great. -Matthias On Tue, Apr 20, 2010 at 9:05 AM, Matthias Wessendorfmat...@apache.org wrote: On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Staretsmax.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and
Re: [Trinidad 2] AJAX branch ready for testing
Am 20.04.10 21:22, schrieb Andrew Robinson: Ajax branch has been merged into the trunk. We'll keep hammering away on the problems that were found (most JSF2, not AJAX related) so we can hopefully stabilize the code for a release in the not too distant future. Hey Andrew sounds good, and feel free to open a jira issue if you run into issues on our sides, we will be happy to fix them for you guys. (and sorry for my reaction before) Werner
Re: [Trinidad 2] AJAX branch ready for testing
_ajaxOldDomElements is code in Page.js, this looks like a bug in Trinidad that needs to be fixed On Fri, Apr 9, 2010 at 8:52 AM, Matthias Wessendorf mat...@apache.org wrote: looks like the 2.0.1 are just labeled as Mojarra 2.0.2 (SNAPSHOT 20091204) I now updated the pom to 2.0.2 and got this log: INFO: Initializing Mojarra 2.0.2 (FCS b10) But the error is the same on the clientBehaviorHolder.xhtml page -Matthias On Fri, Apr 9, 2010 at 4:33 PM, Matthias Wessendorf mat...@apache.org wrote: eh, funny. the pom is actually configured with 2.0.1. Something is going wrong here :-) On Fri, Apr 9, 2010 at 4:15 PM, Max Starets max.star...@oracle.com wrote: Matthias, Are you getting the same results with Mojarra 2.0.1? Max Matthias Wessendorf wrote: hi, I gave it a quick try. Here are my results: Page: http://localhost:8080/trinidad-demo/faces/demos/clientBehaviorHolder.xhtml JSF_RI (Mojarra 2.0.2 (SNAPSHOT 20091204)) results: I entered some text and clicked submit via JSF Ajax Got this (in an alert JS box): httpError: The Http Transport returned a 0 status code. This is usually the result of mixing ajax and full requests. This is usually undesired, for both performance and data integrity reasons. second click on the same button I got this JS error. mojarra is not defined [Break on this error] var func = new Function(event, handler); === the submit button works. MyFaces 2.0.0-SNAPHOT results: (using snapshot since the ViewExpiredException is gone in latest snapshot ) * submit button gives me this ALERT() box: TypeError: this._ajaxOldDomElements is null followed by this: malformedXML-- * Submit via JSF Ajax: I get this alert() BOX: httpError-httpError-Request failed Are there any other pages where I can test the new functionality ? -Matthias On Wed, Apr 7, 2010 at 4:33 PM, Max Starets max.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad 2] AJAX branch ready for testing
The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Starets max.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew
[MyFaces 2] Version 2.0.0 does not work as well (was: Re: [Trinidad 2] AJAX branch ready for testing)
Hi, when I (using the 2.0.0) navigate to this page http://localhost:8080/trinidad-demo/faces/demos/pprDemos.jspx I get a full page reload on every click. = works with Mojarra. -Matthias On Fri, Apr 9, 2010 at 2:55 PM, Matthias Wessendorf mat...@apache.org wrote: https://issues.apache.org/jira/browse/MYFACES-2654 On Fri, Apr 9, 2010 at 2:52 PM, Matthias Wessendorf mat...@apache.org wrote: I now checked this page: http://localhost:8080/trinidad-demo/faces/demos/pprDemos.jspx MYFACES_SNAPSHOT: = on any ajax action/click, I get these two alert() boxes: * TypeError: this._ajaxOldDomElements is null * malformedXML-- == I will file a bug against MyFaces JSF RI (2.0.2): == fine On Fri, Apr 9, 2010 at 2:48 PM, Matthias Wessendorf mat...@apache.org wrote: hi, I gave it a quick try. Here are my results: Page: http://localhost:8080/trinidad-demo/faces/demos/clientBehaviorHolder.xhtml JSF_RI (Mojarra 2.0.2 (SNAPSHOT 20091204)) results: I entered some text and clicked submit via JSF Ajax Got this (in an alert JS box): httpError: The Http Transport returned a 0 status code. This is usually the result of mixing ajax and full requests. This is usually undesired, for both performance and data integrity reasons. second click on the same button I got this JS error. mojarra is not defined [Break on this error] var func = new Function(event, handler); === the submit button works. MyFaces 2.0.0-SNAPHOT results: (using snapshot since the ViewExpiredException is gone in latest snapshot ) * submit button gives me this ALERT() box: TypeError: this._ajaxOldDomElements is null followed by this: malformedXML-- * Submit via JSF Ajax: I get this alert() BOX: httpError-httpError-Request failed Are there any other pages where I can test the new functionality ? -Matthias On Wed, Apr 7, 2010 at 4:33 PM, Max Starets max.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [MyFaces 2] Version 2.0.0 does not work as well (was: Re: [Trinidad 2] AJAX branch ready for testing)
damn cache :-) I closed the issue On Wed, Apr 14, 2010 at 3:26 PM, Matthias Wessendorf mat...@apache.org wrote: Hi, when I (using the 2.0.0) navigate to this page http://localhost:8080/trinidad-demo/faces/demos/pprDemos.jspx I get a full page reload on every click. = works with Mojarra. -Matthias On Fri, Apr 9, 2010 at 2:55 PM, Matthias Wessendorf mat...@apache.org wrote: https://issues.apache.org/jira/browse/MYFACES-2654 On Fri, Apr 9, 2010 at 2:52 PM, Matthias Wessendorf mat...@apache.org wrote: I now checked this page: http://localhost:8080/trinidad-demo/faces/demos/pprDemos.jspx MYFACES_SNAPSHOT: = on any ajax action/click, I get these two alert() boxes: * TypeError: this._ajaxOldDomElements is null * malformedXML-- == I will file a bug against MyFaces JSF RI (2.0.2): == fine On Fri, Apr 9, 2010 at 2:48 PM, Matthias Wessendorf mat...@apache.org wrote: hi, I gave it a quick try. Here are my results: Page: http://localhost:8080/trinidad-demo/faces/demos/clientBehaviorHolder.xhtml JSF_RI (Mojarra 2.0.2 (SNAPSHOT 20091204)) results: I entered some text and clicked submit via JSF Ajax Got this (in an alert JS box): httpError: The Http Transport returned a 0 status code. This is usually the result of mixing ajax and full requests. This is usually undesired, for both performance and data integrity reasons. second click on the same button I got this JS error. mojarra is not defined [Break on this error] var func = new Function(event, handler); === the submit button works. MyFaces 2.0.0-SNAPHOT results: (using snapshot since the ViewExpiredException is gone in latest snapshot ) * submit button gives me this ALERT() box: TypeError: this._ajaxOldDomElements is null followed by this: malformedXML-- * Submit via JSF Ajax: I get this alert() BOX: httpError-httpError-Request failed Are there any other pages where I can test the new functionality ? -Matthias On Wed, Apr 7, 2010 at 4:33 PM, Max Starets max.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad 2] AJAX branch ready for testing
hi, I gave it a quick try. Here are my results: Page: http://localhost:8080/trinidad-demo/faces/demos/clientBehaviorHolder.xhtml JSF_RI (Mojarra 2.0.2 (SNAPSHOT 20091204)) results: I entered some text and clicked submit via JSF Ajax Got this (in an alert JS box): httpError: The Http Transport returned a 0 status code. This is usually the result of mixing ajax and full requests. This is usually undesired, for both performance and data integrity reasons. second click on the same button I got this JS error. mojarra is not defined [Break on this error] var func = new Function(event, handler); === the submit button works. MyFaces 2.0.0-SNAPHOT results: (using snapshot since the ViewExpiredException is gone in latest snapshot ) * submit button gives me this ALERT() box: TypeError: this._ajaxOldDomElements is null followed by this: malformedXML-- * Submit via JSF Ajax: I get this alert() BOX: httpError-httpError-Request failed Are there any other pages where I can test the new functionality ? -Matthias On Wed, Apr 7, 2010 at 4:33 PM, Max Starets max.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad 2] AJAX branch ready for testing
I now checked this page: http://localhost:8080/trinidad-demo/faces/demos/pprDemos.jspx MYFACES_SNAPSHOT: = on any ajax action/click, I get these two alert() boxes: * TypeError: this._ajaxOldDomElements is null * malformedXML-- == I will file a bug against MyFaces JSF RI (2.0.2): == fine On Fri, Apr 9, 2010 at 2:48 PM, Matthias Wessendorf mat...@apache.org wrote: hi, I gave it a quick try. Here are my results: Page: http://localhost:8080/trinidad-demo/faces/demos/clientBehaviorHolder.xhtml JSF_RI (Mojarra 2.0.2 (SNAPSHOT 20091204)) results: I entered some text and clicked submit via JSF Ajax Got this (in an alert JS box): httpError: The Http Transport returned a 0 status code. This is usually the result of mixing ajax and full requests. This is usually undesired, for both performance and data integrity reasons. second click on the same button I got this JS error. mojarra is not defined [Break on this error] var func = new Function(event, handler); === the submit button works. MyFaces 2.0.0-SNAPHOT results: (using snapshot since the ViewExpiredException is gone in latest snapshot ) * submit button gives me this ALERT() box: TypeError: this._ajaxOldDomElements is null followed by this: malformedXML-- * Submit via JSF Ajax: I get this alert() BOX: httpError-httpError-Request failed Are there any other pages where I can test the new functionality ? -Matthias On Wed, Apr 7, 2010 at 4:33 PM, Max Starets max.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad 2] AJAX branch ready for testing
https://issues.apache.org/jira/browse/MYFACES-2654 On Fri, Apr 9, 2010 at 2:52 PM, Matthias Wessendorf mat...@apache.org wrote: I now checked this page: http://localhost:8080/trinidad-demo/faces/demos/pprDemos.jspx MYFACES_SNAPSHOT: = on any ajax action/click, I get these two alert() boxes: * TypeError: this._ajaxOldDomElements is null * malformedXML-- == I will file a bug against MyFaces JSF RI (2.0.2): == fine On Fri, Apr 9, 2010 at 2:48 PM, Matthias Wessendorf mat...@apache.org wrote: hi, I gave it a quick try. Here are my results: Page: http://localhost:8080/trinidad-demo/faces/demos/clientBehaviorHolder.xhtml JSF_RI (Mojarra 2.0.2 (SNAPSHOT 20091204)) results: I entered some text and clicked submit via JSF Ajax Got this (in an alert JS box): httpError: The Http Transport returned a 0 status code. This is usually the result of mixing ajax and full requests. This is usually undesired, for both performance and data integrity reasons. second click on the same button I got this JS error. mojarra is not defined [Break on this error] var func = new Function(event, handler); === the submit button works. MyFaces 2.0.0-SNAPHOT results: (using snapshot since the ViewExpiredException is gone in latest snapshot ) * submit button gives me this ALERT() box: TypeError: this._ajaxOldDomElements is null followed by this: malformedXML-- * Submit via JSF Ajax: I get this alert() BOX: httpError-httpError-Request failed Are there any other pages where I can test the new functionality ? -Matthias On Wed, Apr 7, 2010 at 4:33 PM, Max Starets max.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad 2] AJAX branch ready for testing
Matthias,
Are you getting the same results with Mojarra 2.0.1?
Max
Matthias Wessendorf wrote:
hi,
I gave it a quick try. Here are my results:
Page:
http://localhost:8080/trinidad-demo/faces/demos/clientBehaviorHolder.xhtml
JSF_RI (Mojarra 2.0.2 (SNAPSHOT 20091204)) results:
I entered some text and clicked "submit via JSF Ajax"
Got this (in an alert JS box):
httpError: The Http Transport returned a 0 status code. This is
usually the result of mixing ajax and full requests. This is usually
undesired, for both performance and data integrity reasons.
second click on the same button I got this JS error.
mojarra is not defined
[Break on this error] var func = new Function("event", handler);
=== the "submit" button works.
MyFaces 2.0.0-SNAPHOT results:
(using snapshot since the ViewExpiredException is gone in latest snapshot )
* "submit" button gives me this ALERT() box:
"TypeError: this._ajaxOldDomElements is null"
followed by this:
"malformedXML--"
* Submit via JSF Ajax:
I get this alert() BOX:
"httpError-httpError-Request failed"
Are there any other pages where I can test the new functionality ?
-Matthias
On Wed, Apr 7, 2010 at 4:33 PM, Max Starets max.star...@oracle.com wrote:
Just a few minor additions -
- PartialViewContext.isAjaxRequest() will be returning true for the requests
sent with jsf ajax
as well as the legacy "partialSubmit=true" requests.
- Trinidad's partial triggers will be honored for the jsf ajax requests.
However, this will currently work only with execute="@all". Once we start
adding trigger listeners
during the PostRestoreView event processing, instead of decode, this
limitation will go away.
Max
Andrew Robinson wrote:
Well after a bit of work, the JSF2 AJAX branch is ready for testing to
see if we want to merge it into the trunk.
Branch:
https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3
Details:
- jsf.ajax.request used to submit PPR requests from the request queue
- server serves JSF2 payload, differing if an IFRAME submission is
detected for Trinidad to send down script libraries
- iframe processing through legacy code, but updated to use a valid JSF2
payload
- iframe still sends Tr-XHR-Message to let the server know its a legacy
request
- legacy request supports DOM replacement but none of the new
functionality of JSF2 (attribute updates for example)
- TrPage integrated with JSF2 events to correctly broadcast DOM change
notifications and restore focus
- If users find errors in the jsf.js libraries, setting the
_useJsfBuiltInAjaxForXhr property of the request queue to false will
bypass usage of jsf.ajax. We can add support for a public way of doing
this later if necessary.
- Server side integration with the JSF2 APIs and client behaviors,
JSF2 submission working along side of partialSubmit=true and auto PPR.
Thank you,
Andrew
Re: [Trinidad 2] AJAX branch ready for testing
eh, funny. the pom is actually configured with 2.0.1. Something is going wrong here :-) On Fri, Apr 9, 2010 at 4:15 PM, Max Starets max.star...@oracle.com wrote: Matthias, Are you getting the same results with Mojarra 2.0.1? Max Matthias Wessendorf wrote: hi, I gave it a quick try. Here are my results: Page: http://localhost:8080/trinidad-demo/faces/demos/clientBehaviorHolder.xhtml JSF_RI (Mojarra 2.0.2 (SNAPSHOT 20091204)) results: I entered some text and clicked submit via JSF Ajax Got this (in an alert JS box): httpError: The Http Transport returned a 0 status code. This is usually the result of mixing ajax and full requests. This is usually undesired, for both performance and data integrity reasons. second click on the same button I got this JS error. mojarra is not defined [Break on this error] var func = new Function(event, handler); === the submit button works. MyFaces 2.0.0-SNAPHOT results: (using snapshot since the ViewExpiredException is gone in latest snapshot ) * submit button gives me this ALERT() box: TypeError: this._ajaxOldDomElements is null followed by this: malformedXML-- * Submit via JSF Ajax: I get this alert() BOX: httpError-httpError-Request failed Are there any other pages where I can test the new functionality ? -Matthias On Wed, Apr 7, 2010 at 4:33 PM, Max Starets max.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad 2] AJAX branch ready for testing
looks like the 2.0.1 are just labeled as Mojarra 2.0.2 (SNAPSHOT 20091204) I now updated the pom to 2.0.2 and got this log: INFO: Initializing Mojarra 2.0.2 (FCS b10) But the error is the same on the clientBehaviorHolder.xhtml page -Matthias On Fri, Apr 9, 2010 at 4:33 PM, Matthias Wessendorf mat...@apache.org wrote: eh, funny. the pom is actually configured with 2.0.1. Something is going wrong here :-) On Fri, Apr 9, 2010 at 4:15 PM, Max Starets max.star...@oracle.com wrote: Matthias, Are you getting the same results with Mojarra 2.0.1? Max Matthias Wessendorf wrote: hi, I gave it a quick try. Here are my results: Page: http://localhost:8080/trinidad-demo/faces/demos/clientBehaviorHolder.xhtml JSF_RI (Mojarra 2.0.2 (SNAPSHOT 20091204)) results: I entered some text and clicked submit via JSF Ajax Got this (in an alert JS box): httpError: The Http Transport returned a 0 status code. This is usually the result of mixing ajax and full requests. This is usually undesired, for both performance and data integrity reasons. second click on the same button I got this JS error. mojarra is not defined [Break on this error] var func = new Function(event, handler); === the submit button works. MyFaces 2.0.0-SNAPHOT results: (using snapshot since the ViewExpiredException is gone in latest snapshot ) * submit button gives me this ALERT() box: TypeError: this._ajaxOldDomElements is null followed by this: malformedXML-- * Submit via JSF Ajax: I get this alert() BOX: httpError-httpError-Request failed Are there any other pages where I can test the new functionality ? -Matthias On Wed, Apr 7, 2010 at 4:33 PM, Max Starets max.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad 2] AJAX branch ready for testing
Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew
[Trinidad 2] AJAX branch ready for testing
Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew
