Hey, I'm not sure what the JSR314 spec has to say about it, but are you going to create something to handle session timeouts?
It's a common problem with JEE Ajax apps, because you expect XML or JSON or something, but instead you end up with a login page. What I do on my current project, is checking in JavaScript if the response follows the expected format (in my case, I checked for a specific XML tag). If it doesn't, I know something is wrong and I redirect (document.location="newUrl") to the login page. It might be a good idea to provide a hook in MyFaces for this. AFAIK, the other JSF Ajax frameworks don't have this feature. /JK 2009/4/10 Werner Punz <[email protected]>: > Ganesh schrieb: >> >> Hi, >> >> I'll remove _Extensions. Werner, you'll receive a patch. These are my next >> TODOs: >> >> - Include the context parameter into the xhrCore classes. > > yes that one is important after all the context is sent down to every event > handler... > >> - Move the myfaces params into the context > > yes... just to clarify for the others, we opted to put our specialized > parameters which can adjust the engine on the fly on a per request call > into the options list. The Spec already has specialized options which were > remapped and reprocessed before going into the request, so it is probably > one extension point we can use for our own specialized options. > The other one is a central configuration datastructure which can be defined > on a page per page base! > > >> - Call getViewState() from within xhrCore and route the APIs getViewState >> so xhrCore >> - Make the queue size configurable through myfaces params >> > Again an explanation we try to route calls wherever possible through the > standard apis instead of relying on our internal code! > External APIs are only allowed to call their subsequent adapter > implementation objects, while even the deepest adapter is allowed to call > the API itself! > >> I've got two problems with the JSF 2.0 final spec, maybe anybody on this >> list has got an idea, how to interpret these passages: >> >> - In 13.4.2 the spec says: >>Partial view processing allows selected >> components to be processed through the “execute” portion of the lifecycle. >> ... the “execute” portion ... really is the “Apply Request Values Phase”, >> “Update Model Values Phase” and “Process Validations Phase”. The client also >> sends a set of client ids of the components that must be processed through >> the execute phase of the request processing lifecycle.<< >> >> In 14.1 the spec says for jsf.getViewState: >>Encode the name and value >> for each input element of FORM_ELEMENT.<< >> >> The client ids are sent through the execute parameter of the >> jsf.ajax.request method. Now, wich puzzles me is: Why should the client send >> names and values of ALL input elements if only the ones named in the execute >> parameter are being processed in phase 2-4? Performance would be greatly >> improved by sending only the required parameters. >> >> Looking at the example given is the Javascipt API docs of jsf.ajax.request >> the spec probably wants to imply that the execute paramter should contain >> the pushed buttons name and value to trigger it to queue it's action , but >> this is definitely not covered by the words of the spec. Now here's my >> question: Do we implement what we think the spec was meant to say (and what >> the RI does) or do we implement what the spec actually says? >> >> - 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. > > That causes some back button issues however! > But also have in mind that the new state saving is much more optimized only > storing deltas of components changed so that the queues can be much deeper > on the server! > So instead of having an entire page as changed state per ajax request the > queue now is filled only with one value, the one being changed by the input! > > >> where you would want the server to process 35 JSF request when the user >> has already finished his input. Most of the time submitting the latest >> client state will be appropriate, while all intermediate requests (made >> while the 1st request was running) should become discarded. Wouldn't a queue >> size of 1 be more appropriate for JSF Ajax interaction then an unlimited >> queue size? If we have a consensus on this I would like to post this >> proposal as a MyFaces comment to the JSF 2.0 spec. >> > > 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. > > Anyway here also we are back again to the first question, why the entire > form? > I have no clue, I assume it is probably that you have all values reachable > but still only a subset of them is processed in execute and render. > > Since I am not in the EG > anyone in the EG wants to comment on this. > > 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. > > > Werner > > > > >
