Dan Allen wrote:
Yep, I just picked up on that, thanks to our trusty #jsf2next tag (and the fact that he called us all out by name).

The way I look at it, these guys have the time to sit down, write their thoughts, and, in this case, create a PDF document.
But not enough time to run a spell checker or get all his facts straight. ;)
That means they clearly are trying to communicate with us. Let's parse it, see what action items we can take (could simply be updates to javaserverfaces.org or jsfcentral.com) and roll with it. They are doing the hard work for us, we just have to pay attention.
I agree, while he didn't learn enough to do some basic things in JSF... it shows that a "Senior Java Architect and Developer" with more than 10 years in the J2EE space, isn't getting the information he needs in order to do basic things.

Here's what I heard from the article:

* Best practices in accessing the model layer (initialization) (NOTE: the app I work on solves this by retrieving data from the model before the rendering phase... but that's his point, it's not built-in to the framework)

* Re-initialization -- not sure I completely understand here... if you navigate (even to the same page you're already on), you DO get a new view and it does go through the creation process again.  Not sure if bean's get re-initialized though (I don't even use managed beans b/c they're more hassle than they're worth ;)).

* Tomahawk component issues.  Actually sounds like it might be partially do to the mistake that we allowed JSP's to work with JSF... that part is probably solved by Facelets.

* Finding components -- he didn't know how to use the API.  He had 2 choices: use ":clientId" syntax to findComponent(); or write a brain-dead simple helper method that walks the component tree and looks for a simple componentId match and returns a list (that seems to be what he prefers).  In this case he is just whining and should read the JavaDoc for findComponent... which I find very clear and verbose (good job to whoever wrote that).

* Validation -- I think this could be improved... but he could probably also write a tiny bit of code (since he's a senior Java Architect with 10+ years of J2EE experience) to do the extra validation he needs to do.

* Styling -- We have left this to the component authors, perhaps we can do something to help standardize certain areas of this.  I think most vendors follow some best-practices.  One example he complains about the most (not being able to customize the styles based on component state) seems simply false to me.  Unless I'm missing something obvious, can't that simply be done by binding the styleClass property: styleClass="#{myBean.styleClass}"??  Or using a handler in JSFT where the Java code is re-used -- sorry I couldn't help myself, Ryan.

* He doesn't like the standard components (i.e. panelGrid) -- Show of hands, who does? ;)  Perhaps we're not stating loudly enough that our "standard" components are more like "example components".  I think w/ JSF 2's ease-of-component-creation, this is even less important... but even in 1.2 and earlier, we really don't expect the standard components to be production-components do we??  Apparently he does.

* He re-invented the "binding" property in his suggested "easy way to dynamically set a component".  Although I personally feel like the binding property should be deprecated and a real factory approach should be implemented like in JSFT (that's another topic, though)...  Anyway, he apparently did not know you could already do his proposed solution as of JSF 1.0.

* Mixing components -- we started addressing this big problem in JSF2 and (I think) made huge strides.  We need to continue to identify any remaining issues that prevent component co-existence.  Styling may be the next step...

* He does not view JSF + Component set as developing in JSF.  This is sad as our initial intent was to promote 3rd party component vendors.  Although we do need to fix component interoperability (hopefully JSF2 has mostly done this).

* He views the EG as not willing to listen -- other comments directly disagree.  We should continue to welcome feedback, I think many of you have bent over backward to do this already -- keep it up! :)

Anyway, that's my take on his PDF article (why can't he use HTML -- he's been using J2EE for 10+ years!).

Ken

-Dan

p.s. Keep in mind that I do recognize that e-mail traffic has been heavy and the holidays are approaching, so I'm not pressuring anyone to act immediately. It's just important that we do capture this feedback and do analysis on it in due time. I look forward to what it will reveal.

On Thu, Dec 10, 2009 at 11:49 PM, Lincoln Baxter III <lincolnbaxter@gmail.com> wrote:
from @ptrthomas

U, I and #JSF - "still painful after all these years" http://is.gd/5j3GI

---
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"





--
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