JSF Ajax and Multiple Forms

This blogpost is about a problem which about 80% of all user problems regarding JSF Ajax in the myfaces mailinglist revolve around. Namely how do I handle the jsf ajax in a multiple form scenario.

JSF Ajax and multiple forms, a standard case, which should be easy right.
Let's have a small look at an example:



As we see here, two forms each updating a component in itself via ajax.
Now what happens if we submit the forms alternating.

After a while we run into a ViewRoot cannot be found Exception on the server side.

We did everything right, why do we face this issue?

The answer lies in a bug in the JSF Ajax protocol, more precisely the way the ViewState is processed.

Lets have a look at an Ajax response:



Here we see the root cause of the problem. There is a parameter defining the ViewState with the identifier javax.faces.ViewState, however it is not clear where it belongs to.

Practically a viewstate must be attached to a form. So the issuing form definitely must receive it. However what about the other forms?

And here is the root cause of the error. Only the issuing form is updated and the ViewState which is dependend on the viewroot not the form in the second form is not updated.

This image shows exactly what happens:

As you can see only one form is update the second form now has a viewstate which is not the current one and at one point is dropped from the ViewState history, a classical concurrency issue.

So the solution would be to update all forms in the html document, right?

Theoretically yes, but there is one API which prevents this simple solution. Portlets.
In a portlet environment you have multiple viewroots all belonging to different jsf session instances on the server.


The next logic solution would be to update all jsf elements under ViewRoot.

Again, a good idea, but the protocol prevents it. On the pure client side we do not have any marker or indicator, which tells the ajax code where the current ViewRoot begins.

To ease this protocol problem an extension to the jsf spec was added under 2.1 which eases this problem. According to the spec you have to add the second form manually as render target. Something which both implementations follow. Here is a snippet which shows the solution:



Here we can see, we have added the second form as render target.

Now both forms will be updated and the viewstate always will be up to date.


This solution while being spec compliant is not satisfactory. Sometimes you dont know if a certain form is still present after the ajax case. Is there still a way to update all forms in the page or at least to take the form id out of the equation?

Unfortunately not within the bounds of the specification. However, being aware of this issue, I have added in Apache MyFaces additionally to the spec behavior two other ways to resolve the issue.

First, you don't have to define the form as render target, but you can define any element within a form as render target and the form will be updated.



Secondly, the probably best solution. A configuration parameter which forces MyFaces to update all forms in a page.

With following code snippet you can enable this mechanism:


Once you have added this snippet of javascript, myfaces will be in no portlet mode and will enforce an update all forms with the viewstates policy.

Note: While this method wont break the code if you switch to mojarra, you will not get the benefits, because Mojarra does not yet have a similar solution to the issue.

JSF Ajax Encoding

The entire story started when we got the request to encode everything in ISO-8859-51 including the ajax cycle. Well first I thought it was easy just change the encoding on the javascript side, let the server handle the rest. The encoding was easily detectable on the javascript side simply by checking the xhtmls encoding (the meta tag head encoding itself would have been another option, but since we are nailed down to xhtml anyway due to facelets we have an easier way)
Easy, I thought, but then I ran into browser hell.

The problem normally would be easily resolvable. The XHR object has the option of adding
xhr header content type:

xhr.setRequestHeader("ContentType", "application/x-www-form-urlencoded; charset=ISO-8859-15");

The problem now are the browsers themselves. By testing the dynamic encoding on various browsers following came out:

Browser	Actual Encoding
Mozilla 7	UTF-8
Chrome	UTF-8
IE	ISO-8859-15
Opera	ISO-8859-15

So what does this mean, only opera and IE got it right. Which means the path of allowing non UTF-8 submits is blocked for now.

However JSF automatically deals with the problem properly. While I implemented the most of the Ajax part of myfaces, I have to admit the actual encoding part was provided by another project, namely j4fry and its implementors worked on that part, so I never gave a second thought. However both implementations deal the same way with the issue.

First ajax submits are UTF-8 encoded, this at the first look could pose problems with non UTF pages. It turns out there are none.

The solution both implementations follow is to encode the actual key value pair parameters into a utf url encoded representation.

Both implementations seem to apply the encodeURIComponent function of javascript-
Now now matter what content type the page has, always a proper utf-8 representation of the original content will be passed down.

Given the response type also then is UTF-8 what happens with the response. After all the page needs to handle the response properly in its own encoding.
Well there MyFaces and Mojarra differ slightly. Both in compliance with the spec, encode the response in a XML CDATA block. However MyFaces does additional escaping of non ascii chars with their unicode representation, while Mojarra simply pushes the content byte per byte into the CDATA block.


Here is an example:

Mojarra:



Here it is clearly visible that the cdata block has a different encoding than the outer UTF-8 encoded xml. In the final page representation all the special chars are visible again as they should be.

However MyFaces goes one step further and escapes the content additionally to get rid of the non utf-8 representation of the characters.



However this comes from the fact that myfaces basically also does an escape of special chars at a full page refresh, so the core behavior regarding the partial response is the same.

So what happens for instance if you just tamper with the UTF header.
You automatically will run into problems due to the uri encoded UTF-8 representation of the parameters. In the worst case you will trigger a server error because of non decodable parameters, in the best case if you pass down ascii only chars you will get it through, in the normal case you will get junk in which is wrongly decoded.

See here an example on IE9 and Mojarra:

The question remains, are both save from a client point of view? Theoretically it should be since everything is embedded in a CDATA block.
However I cannot say if the browsers swallow really everything within their browser engines which is embedded in a CDATA block (aka every byte combination outside of their encoding).


It comes down again to the golden rule #1 in web programming, use UFT-8 and never bother with other encodings, if you can. If you have to, be prepared to enter the valley of tears, after all UTF-8 now has been for almost a decade the fix for all the encoding issues in the web space.

Introducing the MyFaces jsf.js Modular Includes

Introduction:

Why modular jsf.js includes, there is one jsf.js file, right?

Since the beginning of the introduction of jsf.js in JSF there has been only one jsf.js file which serves all Ajax needs.
However, at least for Apache MyFaces there have been a lot of extensions added such as:

• iframe ajax fileupload
• html5 form detection
• client side i18n message support for various languages (including chinese)
• legacy browser support down to blackberry 4.7 and winmobile 6.5 and ie6
• browser optimisations for browsers supporting dom level3
• queue control for the ajax request queue
• timeout handling
• better error handling
• delay handling
• modular structure which can be changed at runtime to replace it with your own  implementation of subparts
• clear distinction between api and impl on codelevel

(More info on many of those extended features see following Link)

Most of those extensions will make it one way or the other into the official jsf spec. However different scenarii have different needs.
While most legacy mobile browsers are now slowly phased out (and is seen as deprecated) ie6 for the time being is still supported with a burden of legacy code.
However in a pure modern mobile environment for instance you need smaller files and no legacy code at all. Many users are also perfectly happy with a pure implementation of jsf.js according to the spec without any extra features. Other users only need a subset of those features and want to leave out the other (i18n support for instance)

The advantage of dropping code is smaller filesizes, faster code due to less lines which have to be processed and less fallbacks which have to be prechecked. Something worthwhile to explore given modern mobile browser environments and situations where you simply want to be as lean as possible.

So what is the solution for all this

The MyFaces jsf.js Modular Includes

As of MyFaces 2.1.4 a modular include system will be added. Simply by adding following parameter to your web.xml you will be able to determine what will be included


With the parameter

org.apache.myfaces.JSF_JS_MODE

and the allowed values of

• normal
• modern
• minimal-modern

you will be able to adjust which version of jsf.js is included. If you need extra functionality you can include the subparts excluded from your version as separate Javascript resources via normal jsf mechanisms.

Following image shows the version of each file and the extra functionality:

Modular include parts

As you you can see you can stack and mix all the modules you need by simply choosing a base jsf.js and then you are able to stack the extra functionality needed by adding a separate include.

That way you have the choice between filesize, number of includes and features according to your needs.













Example on how to Enable the Modular Includes with Additional Features

The following example will include the minimal-modern jsf.js and will stack all the extra functionality on top of it.

web.xml



in your page template



As you can see all you need to to is to reference the correct js file additionally which is hosted under the resource module myfaces and you are ready to go.