Hi,
I'll remove _Extensions. Werner, you'll receive a patch. These are my
next TODOs:
- Include the context parameter into the xhrCore classes.
- Move the myfaces params into the context
- Call getViewState() from within xhrCore and route the APIs
getViewState so xhrCore
- Make the queue size configurable through myfaces params
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,
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.
Best Regard,
Ganesh
Werner Punz schrieb:
Sorry for posting all this but Matthias gave me a well deserved smack
on the head that I should post everything publicly into the devs list:
So to sum up the short info, I want to give Alex and Ganesh a short
status update on what has been done, have in mind the affected code
will be committed by me:
Changes since we last synched:
I finalized the namespaces for me, I did a refactoring over the code,
there is still some namespacing which needs to be fixed in xhrCore
myfaces._impl.xhrCore_AjaxRequest should become
myfaces._impl.xhrCore.AjaxRequest since this is your code I will leave
that to you guys for now.
The structure now reflects the directory structure of the codebase:
myfaces._impl._util for the (non public) utils code
myfaces._impl.core for the (public) core code
myfaces._impl.xhrCore for the xhr Adapter code (I would prefer to mark
it as non public as well, but that is up to you guys)
then the public apis are under api but have their own javax.faces and
OpenAjax namespaces..
Have in mind all this is for development only, the maven task will
bundle everything together into one single compressed jsf.js file!
b) My own old codebase Utils classes have been reduced down to the non
redundand parts, they deal mostly with language issues adding
functions missing to the core javascript language
c) My own utils class now is named _LangUtils.js to avoid name clashes
with your Utils.js (Which we should rename _DomUtils.js in my opinion)
d) The entire functionality of Extensions.js has been rebuilt in the
_LangUtils.js class we have to work the code Extension.js provides out
over the next few days/weeks
e) I already added basic delete functionality and eval functionality
in the responsehandler part
What has to be done
a) The attributes implementation is missing for now ( I have to lookup
in the dojo code, there are internet explorer specifics regarding
certain attributes)
b) Extension.js has to be worked out of the code
c) The Extensions response handler is missing for now
d) I have to commit the codebase into myfaces, which will happen tomorrow
Werner
