On 12/11/09 12:57 PM, Kito Mann wrote: I love this quote, "I just hope that for the next JSF release the experts will listen to the people – otherwise I fear JSF will be another technology to be voted down by people’s feet eventually." We're certainly not known for listening to people. God forbid. Ed

No one can argue the fact that right now we have reached a remarkable level of transparency (and we still have ideas in the works, if you can imagine an even better situation). But remember, it is going to take a while to trickle down into the community and get the message out. People are still working off knowledge from 2 - 3 years ago. That is where people are coming from. And that is the reality. So no one is saying that we are deaf today, but rather that people are still talking to us like we are deaf (because back in the old days, that's how it was). -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen

And it's incredible that we delivered that and hence kept it all together ;) Hell, I would argue that we nailed the solution ;) -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen

Hi, The only valid points remaining seem to be the no state --> style support, as well as conditional validations and find component support. For the state styling he even point out at how easy it would be to implement #{component} for conditional styleClass. Of course, #{component} was already public when the article was written but I guess he didn't read that part of the specification. Also, that could be adressed with a skinning engine For the conditional validation, I kind of agree however, but I have yet to think of a really nice way to standaize that. Finally, for the findComponent, I think invokeOnComponent adresses this decently well. Regards, ~ Simon ________________________________ From: jsr-314-open-bounces(a)jcp.org on behalf of Kito Mann Sent: Fri 12/11/2009 12:57 PM To: JSR 314 Open Mailing list Subject: [jsr-314-open] Another big article FYI, I just saw a tweet about another (not positive) article: http://bit.ly/50sA4f. I haven't finished reading it yet, but we should definitely review it and provide a good response. --- Kito D. Mann | twitter: kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com <http://www.virtua.com/> | JSF/Java EE training and consulting http://www.JSFCentral.com <http://www.jsfcentral.com/> - JavaServer Faces FAQ, news, and info | twitter: jsfcentral +1 203-404-4848 x3 Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17

Hi guys, I believe we need to clearly state on such threads what the good and the bad points of these articles are (Marketing again, the others kinda know how to do it). So for the PDF I just read, he was right in: - there is no extremely simple way to do validation across multiple components. time for a multi-validator - we have written one for cs-JSF - do we want to take a look? He was wrong in everything else on the level of 2.0, what I can see. Rebuff of his statements: - CSS style-classes cannot use the internal component states - they can, with #{component} - findComponent doesn´t work - it does, exactly as spec'ed - his suggestion to find any component in the whole tree by an id is outright nonsense. A JSF developer will always have to understand the naming container structure of his page to a certain extent - using a certain component framework ties you to a provider - much more so if you use Wicket, Tapestry or GWT - man, are you bound in this case - the component libraries are not interoperable - yes, they are, in many cases today - but JSF 2.0 tries to solve this problem to a fair extent and I believe it will be successful - his point of initialization is irrelevant with the preRenderView system event of JSF 2.0 (and with a lot of extension frameworks before) - error and exception handling are clean and concise in JSF 2.0 (and implementation specific, it was like this already before 2.0) did I miss anything? In any case, we should listen to him about the multi-validation issue. One thing that should get sorted at some point of time. regards, Martin On Sat, Dec 12, 2009 at 1:04 AM, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces