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:
http://today.java.net/pub/a/today/2006/02/09/file-uploads-with-ajax-and-jsf.html.
I'm problably missing your point - can you please clarify, why iframes
are required?
Best Regards,
Ganesh
