Hi 2014-03-10 14:13 GMT-05:00 Howard W. Smith, Jr. <smithh032...@gmail.com>: > 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. :) >
Yes. If there is a bug in 2.2.1 and there is evidence, I'll do my best for fix it. > >> >> 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, ...) ??? > I have read JSF 2.2 spec fully and there is no special part related to multipart encoding. I don't see how it can work, maybe it is something not documented. I'll review the issue and check an example against latest Mojarra. > >> >> 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? > Let's go to clarify this. First of all, c:forEach has been a broken tag for year. Most people has found many bugs, most of them related to its particular behavior. Since facelets was donated to both Mojarra and MyFaces, both share the same code and has the same problems. Mojarra has not done anything to fix the problems, so they still have the old code, but in MyFaces 2.2.x branch we have tried to fix it once for all. The problem is sometimes in some situations the old code (in Mojarra) works, but in others it just doesn't, it fails in the form of duplicate id exceptions or the state get lost, but for the user point of view sometimes it "looks" like things are working but it is not, it is rotten from the inside. So, the old code is not an option, because it is the worst possible option. The new solution is the way to go, because it solves the problem from root. So, Mojarra implementation is not correct, but just by luck it works in some situations. The solution in MyFaces 2.2.1 is the best we have so far, works in most cases and if there is a bug (I'm working on MYFACES-3867, which claims a problem in a very specific complex case) we'll fix it. I know all this has been annoying and painful, that's the reason why we did it in 2.2.x only, but if we can fix it, it will be great because the component tree will use always PSS in those dynamic parts and that means lower state size, lower session size and better overall performance. > 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. :) In few words, the vision of MyFaces is comply with the spec. But that does not mean that MyFaces will be bug-compatible with Mojarra. I think the code is very good from spec point of view, and each issue found that it has been solved in a different way has been widely discussed. What's happening here is the TCK does not cover a lot of edge cases, and since MyFaces is widely used and many people gives a lot of good quality feedback, it has been possible to fix a lot of issues that Mojarra has not seen yet, or has not been fixed in the right way. One way to see the quality of the code is take a look at the amount of issues solved in each version. In 2.0.10 we solved 72 issues but in 2.0.21 we solved just 2. In 2.2.1 we solved only 12. regards, Leonardo Uribe
