You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Werner Punz <we...@gmail.com> on 2009/04/09 16:20:20 UTC
MyFaces 2.0 status of today (Ganesh / Alex)
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
Re: MyFaces 2.0 Ajax state
Posted by Werner Punz <we...@gmail.com>.
Ok Ganesh to drop you a short note on what has been done.
Since it is easter friday I will stop a little bit earlier than planned:
Ok I prepared two things
a) A <body> fetching code which fetches the body content from a well
formed html string, it should be faster than normal string handling due
to being a precompiled regexp!
This code is needed for stripping body content in the update and
probably insert and delete.
Afair there was something along these lines somewhere defined in the
specs javadocs that we cannot rely on not having html and body tags in
the CDATA blocks of the content!
b) I did some preliminary code for setting the attributes which also
should work out most problems of IE in quirks mode regarding node
attribute setting.
I have tested a but not b this needs further testing (there is no IE vm
on my mac currently), for all other browsers the setAttributes just
delegates into the browsers setAttributes, which works just fine!
You can find both functions in _Utils and can integrate both functions
as you like, they will do the heavy lifting on both areas!
For me next week following is on the table:
Furhter working on the response handling code and adding some
mockup tests via servlets and simulated xml responses!
Also for the others, I already have enabled javascript concatenation and
compression via the standard maven javascript plugins (it was less work
than trying to get our myfaces stuff working) it does not work currently
due to a javascript package overhaul, that will be fixed by me next week
as well!
I have commented the sections out from the pom.xml
Werner
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.
> - 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:
>
Re: MyFaces 2.0 Ajax state
Posted by Ganesh <ga...@j4fry.org>.
Hi,
My response keeps coming back with spam score 6.9. Can please someone
check on this? I've attached the "bad" mail in a zip.
Best Regards,
Ganesh Jung
Re: MyFaces 2.0 Ajax state
Posted by Alexander Bell <Al...@j4fry.org>.
2009/4/10 Ganesh <ga...@j4fry.org>
> 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.
>
>
> Ok, if we provide a configurable queue size I would suggest the following
processing:
Each interaction which triggers an ajax request become a member of the
queue. The interaction needs a snapshot of the current state of the form
fields on the page (except the view-state hidden field).
When the running request is finished, the next request could be sent with
the snapshot-form-fields (actually only the fields which are mentioned in
the "execute"-parameter).
In my oppinion it doesn't make sense to have a queue size greater than one
(in most cases).
Also in the table-scrolling-scenario. Only the last position of the
scrollbar is interesting to get all the rows which I need to show. If there
are several "actions" in the queue it could become a performance issue.
Unfortunately I've don't read the final of the spec. yet but I'm gonna read
it until monday.
cheerz alex
--
Mit freundlichen Grüßen / Kind regards
Alexander Bell
J4Fry OpenSource Community
Internet: http://www.j4fry.org
E-Mail: Alexander.Bell@j4fry.org
Webprofil: http://www.j4fry.org/alexanderbell.shtml
Re: MyFaces 2.0 Ajax JIRA issues
Posted by Werner Punz <we...@gmail.com>.
Ganesh schrieb:
> Hi Werner,
>
> The subtasks of MYFACES-2173 I've created are waiting for patches I'll
> provide during the next days. It seems I have no right to assign them to
> myself. Can you do that for me?
>
> [
> https://issues.apache.org/jira/browse/MYFACES-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
>
Seems like only committers can be assignees if you want I could assign
it to me for now...
Werner
MyFaces 2.0 Ajax JIRA issues
Posted by Ganesh <ga...@j4fry.org>.
Hi Werner,
The subtasks of MYFACES-2173 I've created are waiting for patches I'll
provide during the next days. It seems I have no right to assign them to
myself. Can you do that for me?
[ https://issues.apache.org/jira/browse/MYFACES-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Best Regards,
Ganesh
Re: MyFaces 2.0 Ajax state
Posted by Werner Punz <we...@gmail.com>.
Indeed it would, but as I said that would bend the spec
and probably should only be enabled by configuration...
I just wonder why the EG did not add this to the spec.
I even mentioned it to some EG members privately!
I assume that they thought that this corner case can be covered
on component level as well, by providing ajaxing fileupload components
which add a dummy form and iframe to the page, if used!
Werner
Ganesh schrieb:
> I've rechecked and realized that the solution in that today.java.net
> link uses iframe too, so now I agree that iframe is required for ajax
> fileupload. Would make a nice extension to make MyFaces the better Ajax
> JSF solution.
>
> Werner Punz schrieb:
>> Ganesh schrieb:
>>
>>>> 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?
>> You need a multipart request and the file upload component cannot
>> upload via ajax generally to my knowledge there is no way a fileupload
>> can send its content data via ajax only its value, it is a security
>> issue!
>>
>> As for commos fileupload nothing is wrong with it :-)
>> My point was that the spec does not cover this corner case and leaves
>> out fileuploads via ajax!
>>
>
Re: MyFaces 2.0 Ajax state
Posted by Ganesh <ga...@j4fry.org>.
I've rechecked and realized that the solution in that today.java.net
link uses iframe too, so now I agree that iframe is required for ajax
fileupload. Would make a nice extension to make MyFaces the better Ajax
JSF solution.
Werner Punz schrieb:
> Ganesh schrieb:
>
>>> 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?
> You need a multipart request and the file upload component cannot
> upload via ajax generally to my knowledge there is no way a fileupload
> can send its content data via ajax only its value, it is a security
> issue!
>
> As for commos fileupload nothing is wrong with it :-)
> My point was that the spec does not cover this corner case and leaves
> out fileuploads via ajax!
>
Re: MyFaces 2.0 Ajax state
Posted by Werner Punz <we...@gmail.com>.
Ganesh schrieb:
>> 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?
You need a multipart request and the file upload component cannot upload
via ajax generally to my knowledge there is no way a fileupload can send
its content data via ajax only its value, it is a security issue!
As for commos fileupload nothing is wrong with it :-)
My point was that the spec does not cover this corner case and leaves
out fileuploads via ajax!
Re: MyFaces 2.0 Ajax state
Posted by Ganesh <ga...@j4fry.org>.
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
Re: MyFaces 2.0 Ajax state
Posted by Ganesh <ga...@j4fry.org>.
Hi,
Werner, I'm not sure, if the security manger / redirect solution is the
correct approach.
JSF 2.0 provides event and error listener queues on the Javascript side.
In case of an AJAX POST that doesn't find a valid session it should be
appropriate to return a session timeout error. The spec doesn't mention
this specific case, but errors in general are returned via an error tag
in the AJAX XML and if the client has registered an error funciton it
will be triggered. The client code then can decide how to handle the error.
Best Regards,
Ganesh
Werner Punz schrieb:
> Jan-Kees van Andel schrieb:
>> 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.
>>
> Actually the JSR has a special redirect response in the ajax part...
> A security manager in the application can provide such a response
> which then forces the javascript to redirect to the provided page!
>
> I dont think this should be part of the core code :-), since security
> concerns are part of the application and have to be dealt there!
>
>
>
> Werner
>
Re: MyFaces 2.0 Ajax state
Posted by Werner Punz <we...@gmail.com>.
Jan-Kees van Andel schrieb:
> 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.
>
Actually the JSR has a special redirect response in the ajax part...
A security manager in the application can provide such a response which
then forces the javascript to redirect to the provided page!
I dont think this should be part of the core code :-), since security
concerns are part of the application and have to be dealt there!
Werner
Re: MyFaces 2.0 Ajax state
Posted by Jan-Kees van Andel <ja...@gmail.com>.
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 <we...@gmail.com>:
> 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
>
>
>
>
>
Re: MyFaces 2.0 Ajax state
Posted by Werner Punz <we...@gmail.com>.
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
MyFaces 2.0 Ajax state
Posted by Ganesh <ga...@j4fry.org>.
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
>