Ajax Panel Limitations

In the previous post, we discussed the main strategy behind Ajax support in jspx. In this post we will not go through how to use Ajax in jspx as there is already a good article on the website about using ajax in jspx. you can read it from here.

However, if you follow the release notes of jspx, there is a section for the known issues listed as
    1- Ajax validation is not working with auto refresh feature, so if the content of auto refreshing panel has a validation group, the validation will be true always.
    2- Using dispatch with AjaxPanel will cause displaying the new dispatched page within the AjaxPanel. (Use the post normal feature to overcome this).
    3- DataTabel should have PK, if not the edit and delete feature will apply to all records.
    4- portlet pages cannot post back correctly.



Two points out of four concern Ajax. Let's see more about these points.

The first point is describing an issue with AjaxPanel that has an auto refresh feature. Auto refresh feature is allowing the Panel to periodically refreshing its content. This feature is suitable for news content and any other frequently changing sections in a web page.
The auto refresh is easily applied using the same AjaxPanel tag and just adding tow more attributes

1. onrefresh the name of the event handler that will be fired when the panel is refreshed.
   
2. refreshtime the time in millisecond after which the panel will refresh its content
   

an example of auto refresh panel is shown below.

Sometimes the HTML within the AjaxPanel has a client side validation. In order to execute validation when an auto refresh panel is used, an extra tag is used
Group which is set to the name of the validation group that will be executed.
More information about validation are found in the jspx website


The issue is that if the form within the auto refresh ajax panel has an invalid data, the validation result will be true and the refresh event will reach the server.

Tracing this issue showed that the validation is fired and the result is false (as expected) but the panel just keep posting !


I think we would give it some time to find out the reason for that.


For the second one, it seems very lazy bug. I member when this first comes out, the solution was very  easy that we kept delaying so many times. May be it will be targeted in the upcoming build.

Now let's check out the problem, Using AjaxPanel (Normal, Auto Refresh) will inovke your server side event handling java code. This code may try to dispatch or redirect the user to another page. This action will cause the normal execution of the current page to be  overridden and the new page (the user is dispatched to) will be rendered instead, and in case of redirect, the current execution of the page will be skipped also the the redirect code HTTP 302 to be sent to the client targeting the browser to get new resource.

This situation is normally served by the browser in normal posting pages (non-ajax). however when using AjaxPanel, the ajax.js file is taking control of every thing.  So let's see what happen if a server side code invoked from an ajax panel is making either redirect or a dispatch.

In case of redirect the response code will be 302 as stated above, hence it is very easily in the javascript receiving the response to check the response code.
If it is 302, then the new location is extracted from the response header and then the current DOM Document location is changed to the new location.

In case of dispatch, the response code will be 200 just like any normal response. This will cause the response content to replace the content of the AjaxPanel fired the event. Which will make a funny look of the page where a different page will be displayed within your original one!


There is a temporary solution to overcome such limitation, which is to force the control that is firing the event to post its data normally instead of Ajax. That solution is very poor in my personal opinion.
Another suggestion is to issue redirect instead of dispatching, causing the page to refresh its content with the new resource. Which I find a penny more than the former solution.


On the jspx level, solving this problem will add extra header in the response flagging a dispatch operation. Hence the script will understand that flag and use the whole response content to replace the whole document.


We did not try this yet, but this may be a solution for such limitation.