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)
