myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Punz <>
Subject Re: jsf.js post 2.3 plans
Date Mon, 09 Oct 2017 09:48:57 GMT
Just to clarify it:

Before the update it looks like

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)

The final rendered form is now:

EjSU7V49OrNPDglILvevt4kDdHyuyORwVxrmPKQfWqfKBXoi 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.



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 
>> <> 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.

View raw message