myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Punz <werner.p...@gmail.com>
Subject Re: Myfaces 2.0 and xhr transport
Date Mon, 09 Feb 2009 11:58:37 GMT
Ups please ignore the mail, first of all it was an older draft,
secondly the second part is not valid anymore, the ri has clear 
mechanisms on eval by having an eval command in the xml!...
I accidentally sent that and cannot revoke it anymore.

Werner


Werner Punz schrieb:
> Matthias Wessendorf schrieb:
>>> The Trinidad request queue has about 1000 lines of code, 80% of it(the
>>> entire iframe part, multi part form posts, the abstractions to hide
>>
>> regarding iframe:
>> that is needed when you do an "ppr for a form that contains an upload".
>> XHR does not support that.
>>
>> So, you are saying the spec does only support XHR for ajax form submits ?
>> That would be sweet... But that would fit the current ignorance of 
>> Java EE land
>> to generally (out of the box) not support (out of the box) the upload
>> case at all
>> (meaning, there is no standard API for processing uploads, every 
>> framework has
>> its own).
>>
> I would not be so harsh all this currently is a huge work in progress as
> I could see from the differences between the spec and the RI...
> 
> Well there are two things, currently, since I am not in the EG I have
> only info from what I can gather from the released pdfs and javadocs
> and from the RI. The RI always seems to be ahead from the released PDFs
> so I usually take it as my core reference.
> 
> a) I am aware of the upload issue and that you can only do it via
> iframes if you want to stay on a clean html side. I will give a short
> info on what I could gather from the spec and RI:
> 
> Sending a form is, that you have to gather the viewstate and you have to
> send it as encoded String!
> also you have to add various parameters and you can define a map of
> passthrough values which have to be encoded similarily on the client side!
> 
> The request must be queued and it must be send asynchronously.
> It is not clearly stated that you have to use xmlhttprequest for
> sending, the RI however currently uses xmlhttprequest only!
> 
> Not sure if you can say an iframe post is an asynchronous post, but I
> assume so...
> 
> 
>> So, wouldn't that also mean there is no chance in doing "PPR form
>> submit" for upload cases, in
>> a standard way? Wouldn't that cause forks, different APIs etc for
>> different toolkits
> 
> At the current state of the RI is not, and I am not sure if the spec has
> this loophole open, but as it is this needs to be clearly specified one
> way or the other!
> Otherwise we will have the next mess on our hands!
> 
> The spec is rather vague on all this and the issue is that the RI as
> core reference at the last public release (which funnily is not the same
> as the last public released specs, the RI clearly is from mid december
> while the pdfs are from november), does not cover it yet, either means
> they are not aware of those issues or they simply do not have tackled it.
> 
> There is another things, maybe I missed here something, but the response
> data format, is an xml crud format with explicitely stated create update
> delete comments, which is ok, but it does not seem to enforce the split
> between raw html and script code.
> The problem with this is, that browsers must!!!! evaluate the
> javascripts in ppr cases after all the dom updates via innerHTML are
> done. The problem is, modern browsers do not do an auto execution of
> embedded scripts in xhr cases (the last one doing this was ie5 afair, it
> was omitted due to security issues)!
> 
> The workflow usually is .... xhr state finished -> push in the new html
> code via innerHTML, eval all the scripts after the innerHTML is done so
> that they again can work on a stable dom tree.
> 
> Trinidad does this splitting via the responseWriter to get a good
> performance. As I see it for now, the dataformat leaves this hole wide
> open. But as I said this information stems mostly from looking at the
> dataformat itself, I might have missed some info here (I have yet to
> look at the RI how they do it)
> 
> 
> 


Mime
View raw message