On Mon, Feb 9, 2009 at 10:21 AM, Werner Punz <[email protected]> wrote: > 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...
sure, here we should just implement that. I don't think that the TCK does check for "Iframe communication channel presen" :-) > > 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! which would cause serious bugs when one uses uploads :-) > > 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! > My per > > 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. IMO it is not the fault of JSF, that there is this unhappy situation w/ uploads, Java EE, or Servlet 3, should address that. If upload was supported as first class citizens in the JavaEE *umbrella* land, JSF spec would be more aware of it. Well, let's see what the final spec will contain. FYI. I pinged Andy Schwartz on this, how is Oracle's JSF spec dude. -Matthias > > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
