Hi Karl 2014-03-10 15:15 GMT-05:00 Karl Kildén <karl.kil...@gmail.com>: > Hi Leo, > > Upgraded to 2.2.1 today (or was it yesterday?) and had problems. Removed > org.apache.myfaces.STRICT_JSF_2_FACELETS_COMPATIBILITY and many problems > went away. Much later discovered more problems but it's just me and my > silly app until I have proof :-) > > I totally agree that c:forEach was more broken before! Thanks a lot for > fixing it. >
I have found the problem related to MYFACES-3867, so I have already fixed the code in trunk. I think this bug deserves a quick-fix release. > I would be very interested in some more input / clarifications about my > other problem actually. Are you saying that forms may not > use enctype="multipart/form-data"? How are you supposed to > fileUpload? Perhaps you must have a fileUpload component present if the > form has enctype="multipart/form-data"? Sounds like a weird limitation. My > functional requirement is of course a form with a fileupload component, it > is not working though and it's because the form will not post. I ended up > removing all markup until I had a single button in a form and it still did > not work, that's when I created a jira. But at one point that form did have > a fileupload too with no difference in the result. > > The example provided by Michael Kurz in: https://github.com/jsflive/jsf22-examples/blob/master/jsf22-input-file/src/main/webapp/upload.xhtml <h:form id="form" enctype="multipart/form-data"> <h:messages/> <h:panelGrid columns="2"> <h:outputText value="File:"/> <h:inputFile id="file" value="#{uploadPage.uploadedFile}" validator="#{uploadPage.validateFile}"/> </h:panelGrid> <h:commandButton value="Upload File" action="#{uploadPage.uploadFile}"/> <h:commandButton value="Upload File (Ajax)" action="#{uploadPage.uploadFile}"> <f:ajax execute="file" render="@all"/> </h:commandButton> <h:panelGrid id="content" columns="1"> <h:outputText value="Content:"/> <h:inputTextarea readonly="true" value="#{uploadPage.fileContent}" rows="10" cols="100"/> </h:panelGrid> </h:form> Look the enctype="multipart/form-data" is there, but the code also needs the h:inputFile. I don't see how it can work with just the button. <h:form id="mainForm" enctype="multipart/form-data"> <h:commandButton value="Press me" action="# {bean.test}"/><br/> </h:form> I can see the example in the rar file: <h:form id="mainForm" enctype="multipart/form-data"> <h:panelGrid columns="2"> <h:outputLabel for="name" value="Please enter your name"/> <h:inputText id="name" value="#{helloWorld.name}" required="true"/> </h:panelGrid> <h:commandButton value="Press me" action="#{helloWorld.send}"/><br/> <h:messages showDetail="true" showSummary="false"/> </h:form> but the same, it requires the h:inputFile so the file is uploaded. Servlet 3.0 implementation handles the request, and JSF uses the spec, so if the servlet spec works JSF should work. regards, Leonardo Uribe > > > > > On 10 March 2014 21:01, Leonardo Uribe <lu4...@gmail.com> wrote: > >> 2014-03-10 14:56 GMT-05:00 Karl Kildén <karl.kil...@gmail.com>: >> > Ah the new release, yes I tried it asap it did not fix my issue. >> > >> >> Which one? #1 or #2 ? >> >> > Regarding the duplicated id issue that I think could be related to >> > c:forEach, No idea what the problem is but it works fine with mojarra and >> > just as fine with myfaces 2.1.x. The construct in that app is special so >> it >> > is up to me to reproduce it and I don't have time until next week. And >> yes, >> > c:forEach works with ajax but it's important that the items are unchanged >> > during postback. >> > >> >> Ok. If we have an example we will be able to fix it more quickly. For now >> I'll take a look at MYFACES-3867 >> >> > I am considering mojarra because enctype="multipart/form-data" is not >> > working for me with any myfaces 2 version. It's common knowledge that >> > Mojarra is skimping on some validation here and there. >> > >> > >> > On 10 March 2014 20:13, Howard W. Smith, Jr. <smithh032...@gmail.com> >> wrote: >> > >> >> response inline, >> >> >> >> On Mon, Mar 10, 2014 at 2:43 PM, Karl Kildén <karl.kil...@gmail.com> >> >> wrote: >> >> >> >> > Hi Howard, >> >> > >> >> > If someone proposed a fix for me I must have missed it, so no my >> issues >> >> are >> >> > still not resolved unfortunately. I don't think it's possible to >> write it >> >> > in another fashion. >> >> > >> >> >> >> Leonardo's response, asking you to try MyFaces 2.2.1, which was released >> >> within the last 12 to 24 hours. :) >> >> >> >> >> >> > >> >> > Problem #1: enctype="multipart/form-data" not working. Not sure if >> anyone >> >> > tried the demo app I linked in the jira but for now I can't >> investigate >> >> it >> >> > any further on my own. >> >> > >> >> >> >> i don't think Leonardo's response was targeting this issue. >> >> maybe/hopefully, Leonardo will respond at his earliest convenience. >> >> earlier, did you say that this issue is resolved via Mojarra 2.2.x (and >> >> some other container... glassfish, jboss, ...) ??? >> >> >> >> >> >> > >> >> > Problem #2 I also have a problem with duplicated id's but it would >> take >> >> > some time to reproduce it in a demo app so I'm hesitant to bring it >> up. >> >> > Basically a lot of ajax, dynamic includes, c:forEach, ui:repeat, some >> >> > bindings :-) >> >> > >> >> >> >> did you try MyFaces 2.2.1 release to see if the duplicated IDs issue is >> >> fixed in your app/project? >> >> >> >> is it best to assume that c:forEach is supposed to work with/via AJAX >> PPR? >> >> just because Mojarra 'works', should we assume that Mojarra's >> >> implementation is correct? >> >> >> >> MyFaces and TomEE committers know that there MyFaces may be a bit more >> >> 'strict' than Mojarra (I can agree with that as well, as per my >> experience >> >> when i migrated from Mojarra 2.1.x to MyFaces 2.1.x), and I think >> MyFaces >> >> (and TomEE) committers question the fact that Mojarra is really meeting >> >> requirements of the spec, or there is a different set of TCKs that >> Mojarra >> >> is running against. I hope 'they' will confirm, clarify, or correct what >> >> I'm stating here. :) >> >> >>
