myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ganesh <>
Subject Re: MyFaces 2.0 Ajax state
Date Fri, 10 Apr 2009 15:19:35 GMT
Hi again,

>> - Now here's my second problem: In 13.3.2 the spec says: >>All Ajax 
>> requests must be put into a client side request queue before they are 
>> sent to the server to ensure Ajax requests are processed in the order 
>> they are sent.<<
>> So, if you trigger a queue of n Ajax requests each of them would 
>> include the same ViewState that was collected at the time when the 
>> request was queued. But with each response the view state will have 
>> changed, making the former collected view state obsolete! With 
>> javax.faces.STATE_SAVING_METHOD==server the old view state may even 
>> be gone if the queue size exceeds the number of view states stored in 
>> the session. Also, with Ajax requests is it hard to think of a szenario, 
> I dont think this is an issue the view state is probably updated with 
> each request and hence it does the states on every ajax request.
Yes, the view state is updated with each request, but view state is 
collected before queuing a request. This is stated in the Javscript docs 
of jsf.ajax.request and it's implemented this way in the RI, so a 
queuesize superceeding the number of stored view states would probably 
break the system.
> The problem is this depends on a case by case base, I donĀ“t think 
> there is an ideal solution.
> For instance the infamous data scroller is definitely something you 
> cannot use with a queue size of 1, after all you dont want to use 
> scrolling events if you want to keep the pages in between somehow in a 
> scrolling div.
> The queue size of 1 however is feasable probably for certain input 
> szenarios (while it probably fails on per component validation 
> usecases where single components are rerendered)
> My personal preference would be since we are going for internal 
> configuration options anyway for binding the layers, to enable a queue 
> size via configuration
> so that page authors can cut the corner cases by applying spezialized 
> myfaces logic.
Yes, MyFaces will be able to fix this via a myfaces.queuesize parameter.
> There is another big issue, which I have pointed out to some members 
> in the EG already.
> While the spec does not really explicitely state that xhr has to be 
> used as transport, and wisely so, we have a huge problem on our hands 
> specwise.
> The spec says, the transport has to be queued and done asynchronously 
> the form values have to be encoded programmatically by getViewState 
> before being sent down (no form submit).
> What this means is, that ppr of fileupload inputs is out of the game. 
> To enable this you must use form submits with iframes as targets.
> That does mean you cannot fullfill the spec if you want to support that?
> Well before the argument crawls up, that JEE does not support file 
> uploads by now, this argument is invalid because we only talk client 
> side here, it does not matter for now if the servlet api supports full 
> multipart requests by now, at least not for me.
> We have a usecase here which about 100% of all users need!
> All I can think of now is again a special configuration option to 
> enable iframe transports and bend the spec in this regard as well. So 
> that the base spec is covered as it should be and iframe transport is 
> added in the fileupload case.
What's wrong with commons - fileupload? Here's an article on how to 
integrate it with JSF: 
I'm problably missing your point - can you please clarify, why iframes 
are required?

Best Regards,

View raw message