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
