On Mon, Feb 9, 2009 at 11:10 AM, Simon Kitching <[email protected]> wrote: > Matthias Wessendorf schrieb: >> 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. > > Just curious, but I don't see why you say this is a JEE/Servlet issue.
Well.. there is NO unified API for doing file uploads. Every framework like Struts, Wicket, or any JSF extension (Tomahawk, Trinidad) has do build a more natural API for doing file uploads. In vanilla Servlet land all you do is reading bytes. I think (perhaps it is only me) there should be a better support for that on the Servlet layer. > > 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. nobody said that this is possible. And yes you are right. Also(on a side note) with JS you even can't reset the "value" of an <input type:file ... > HTML element. Something like: inputFileHTMLElement.value = null; does not work as well. > > 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? I think yes. A good framework should just help the user (-> page developer) here. -Matthias > > Regards, > Simon > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
