Hi Werner, I had a mvn clean package of core and checked it from IE 11 and it works very good. The fix works fine with repeated ajax calls now! Thanks & Regards, Dora Rajappan. . On Monday, October 9, 2017, 3:19:19 PM GMT+5:30, Werner Punz <werner.p...@gmail.com> wrote: Just to clarify it:
Before the update it looks like https://gist.github.com/werpu/ 071e11cc6328f9f439a6342b0e128e c8 Both forms have a viewstate element. Before my fixes, the viewstate of the first form was gone. Hence you ran into issues: After my yesterdays update the result now looks like following (I got a validation error so the viewstate is recycled in the response which looks like) https://gist.github.com/werpu/ 172786afcdf6514b6120379ab5e236 ce The final rendered form is now: https://gist.github.com/werpu/ cd85343ddc42ef8857a806d8fe06e2 33 EjSU7V49OrNPDglILvevt4kDdHyuyO RwVxrmPKQfWqfKBXoi on form 1 and 2 being the same. Before my patches, only the second form hat a valid viewstate element set and hence you ran into viewstate issues. Please check the jsf.js your browser is loading, if you got the old version in, it looks like it. The build should have produced one with the new version, but jsf.js is never checked in, it is built by the build system. Check your browsers jsf.js for something like mfInternal.namingModeId This is only in my patch but not in the old codebase. Cheers Werner Am 09.10.17 um 11:34 schrieb Werner Punz: > Hi Dora, what do you mean that the > behavior of repeated ajax calls is same? > > > I tried your example yesterday after building the final js file via a > mvn build and before > only the second form got an ajax viestate update > now both forms get one. > > What behavior do you get? > Did you make a proper mvn clean install to get the latest jsf.js in? > > ajaxresponse22.js was deleted because it is dead code it accidentally > was in the codebase, ajaxresponse.js now updates all forms in a > multiform environment under a given view root. In your example > the viewroot is the body element. > > > > > > Werner > > > > Am 09.10.17 um 10:46 schrieb Dora Rajappan: >> Hi, >> >> Thank you very much for the fix Werner. >> I took the latest core today and built it and tested from payara >> without any config changes. Found ajaxresponse22.js deleted and >> ajaxresponse.js changed. >> And the behavior of repeated ajax calls is same. >> Can we have the config changes exactly if any in this manner? I >> checked 4160 and quickly not make out the config changes. >> <context-param> >> <param-name>xyz</param-name> >> <param-value>abc</param-value> >> </context-param> >> >> Thanks & Regards, >> Dora Rajappan. >> On Sunday, October 8, 2017, 7:39:48 PM GMT+5:30, Werner Punz >> <werner.p...@gmail.com> wrote: >> >> >> No sync with Mojarra I have discussed that a while ago. >> The problem is a licensing problem. Mojarra basically can use >> our code but not vice versa, because the CDDL cannot be implemented in >> ASF2 code. >> >> The ASF2 license is a very liberal license, but due to the fact that it >> is so liberal, it is impossible to integrate less liberal code in our >> codebase. >> >> As for your repeated Ajax problems MYFACES-4160 that is a really old >> spec bug which reared its ugly head in multiform scenarii. >> I worked around that by providing a special config param. >> With JSF 2.3 it finally will be fixed. >> >> >> >> Werner >> >> >> Am 06.10.17 um 11:59 schrieb Dora Rajappan: >> > Thanks for detailing the future of browser and how jsf cope up with >> it. >> > >> > I was using mojarra for my application and the commandLink was not >> > working due to script problem. >> > So I switched to myfaces and we got some problem with repeated ajax >> > calls. (Myfaces 4160). >> > >> > Are we syncing with mojarra regarding the technology to be used >> with the >> > jsf.js, entire scripting arena. >> > Not sure spec say anything about the technology used for scripting. >> > >> > Thanks & Regards, >> > Dora Rajappan. >> >> > > >
