I consider the "JSF-is-hopeless" megaphone to be hype also. :) I
really do think JSF has great potential, especially as tools vendors
latch onto it. What I object to is the "JSF-is-here-Struts-is-dead"
hype. My personal belief is that JSF itself -- the technology that was
described in David's article -- will succeed mainly in the view tier.
In my opinion, it is not the best option for a comprehensive app
framework... but then again, a benefit of it being consummately
pluggable is that it can integrate with other technologies. Including
Struts or other controller frameworks.
...Classic and Shale can be healthier together than apart.
+1
BTW, there's been some blurring of the distinction between Shale and JSF
(a distinction which does exist for now ;) ). I'm talking about JSF
alone here, as was the "Top Ten Reasons..." article. I think that
Shale, while it can't be trumpeted as a Standard the way JSF is, adds
enormous value to JSF.
Rich
p.s. In some ways, JSF is a direct competitor to ASPX in ASP.NET, which
is still figuring out the whole navigational-controller thing. In the
rare event that I imagine myself to be on a "side", in a "battle", I
consider myself to be on the side that contains JSF+Struts+Shale,
looking across the field at ASP.NET. :) And even then, I'm only on
that side because I want the more community-driven ecosystem to prevail.
Ted Husted wrote:
On 8/15/05, Rich Feit <[EMAIL PROTECTED]> wrote:
In general, I agree with the sentiment that there's a lot of hype in
this arena, and not all of it is easily backed up. But the Struts
community has always been a bit hype-adverse, no?
Once upon a time, people were saying the same sort of things about
custom tags that people now say about JSF. It's too new, it's too fat,
scriplets are faster. We already know how to use scriptlets, why fuss
with tags?
And, all of those statements were true. In the beginning, custom tags
were slower than scriplets. Five years ago, custom tag compilers were
naive and generated sad, bloated code. But, many of us saw the
potential in custom tags, and we bit the bullet and took the hit.
Sure, the code was sad, but in the greater scheme of things, the tags
are lost in the rounding, and such things are easily fixed by
improving the compiler. The long-term architectural gains custom tags
provided, many of us believed, were worth the short-term code bloat.
Compilers did improve, and all the work we did with custom tag
suddenly became more valuable.
Custom tags were a pardigm shift for many teams then, and components
are a paradigm shift for many teams today. From experience, many of us
know that custom tags provide many benefits in terms of fast
deployment and easy maintenance. And, from experience, many of us
already know that components provide benefits in terms of fast
deployment.
Over time, will components also provide the benefits of easy
maintenance? Hmmm, probably. Check back in 2010, and then we'll know
for sure :)
In the meantime, those of us interested in Struts Classic will
continue to work on Struts Classic, and those of us interested in
Struts Shale can spend our volunteer hours there.
Like two flowers planted in the same bed, Classic and Shale can be
healthier together than apart. Synergistically, roots can intertwine
and reinforce each other, making two together stronger than either
apart.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
