Matthias Wessendorf schrieb: > On Mon, Feb 9, 2009 at 10:21 AM, Werner Punz <werner.p...@gmail.com> 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.
Just curious, but I don't see why you say this is a JEE/Servlet issue. As I understand it, XmlHttpRequest works by manually iterating over the html DOM to find the input widgets, fetch their name+value, and then add the name+value to the XmlHttpRequest. But it is simply not possible to "fetch the value" (file contents) of a file upload widget from javascript; therefore it is never possible to send the contents of a file within an XmlHttpRequest. I would guess that Mojarra just ignores any file-upload widgets when building an XmlHttpRequest, ie partial-submit works fine except that any specified file is ignored. That doesn't seem to unreasonable to me considering the html limitations and that file-upload is fairly rare; just *don't* use them with partial submit. Is the extra complication of a whole iframe-based solution *just* to handle this case really worth it? Regards, Simon
