<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Dan Allen wrote:
<blockquote
cite="mid:19758da0912102102o343d6a42n22ba7fae67b0014b@mail.gmail.com"
type="cite">Yep, I just picked up on that, thanks to our trusty
#jsf2next tag (and the fact that he called us all out by name).<br>
<br>
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.</blockquote>
But not enough time to run a spell checker or get all his facts
straight. ;)<br>
<blockquote
cite="mid:19758da0912102102o343d6a42n22ba7fae67b0014b@mail.gmail.com"
type="cite">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 <a moz-do-not-send="true" href="http://javaserverfaces.org">javaserverfaces.org</a>
or <a moz-do-not-send="true" href="http://jsfcentral.com">jsfcentral.com</a>)
and roll with it. They are doing the hard work for us, we just have to
pay attention.<br>
</blockquote>
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.<br>
<br>
Here's what I heard from the article:<br>
<br>
* 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)<br>
<br>
* 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 ;)).<br>
<br>
* 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.<br>
<br>
* 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).<br>
<br>
* 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.<br>
<br>
* 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.<br>
<br>
* 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.<br>
<br>
* 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.<br>
<br>
* 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...<br>
<br>
* 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).<br>
<br>
* 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! :)<br>
<br>
Anyway, that's my take on his PDF article (why can't he use HTML --
he's been using J2EE for 10+ years!).<br>
<br>
Ken<br>
<blockquote
cite="mid:19758da0912102102o343d6a42n22ba7fae67b0014b@mail.gmail.com"
type="cite"><br>
-Dan<br>
<br>
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.<br>
<br>
<div class="gmail_quote">On Thu, Dec 10, 2009 at 11:49 PM, Lincoln
Baxter III <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:lincolnbaxter@gmail.com">lincolnbaxter@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">from
@ptrthomas<br>
<br>
U, I and #JSF - "still painful after all these years" <a
moz-do-not-send="true" href="http://is.gd/5j3GI" target="_blank">http://is.gd/5j3GI</a><br>
<br>
---<br>
<font color="#888888">Lincoln Baxter, III<br>
<a moz-do-not-send="true" href="http://ocpsoft.com" target="_blank">http://ocpsoft.com</a><br>
<a moz-do-not-send="true" href="http://scrumshark.com"
target="_blank">http://scrumshark.com</a><br>
"Keep it Simple"<br>
<br>
<br>
</font></blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Dan Allen<br>
Senior Software Engineer, Red Hat | Author of Seam in Action<br>
Registered Linux User #231597<br>
<br>
<a moz-do-not-send="true" href="http://mojavelinux.com">http://mojavelinux.com</a><br>
<a moz-do-not-send="true" href="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</a><br>
<a moz-do-not-send="true"
href="http://www.google.com/profiles/dan.j.allen">http://www.google.com/profiles/dan.j.allen</a><br>
</blockquote>
</body>
</html>