Jacob,
I've noticed you're really busy trying to get the 'facelet' message across.
http://www.theserverside.com/news/thread.tss?thread_id=35900
http://www.theserverside.com/news/thread.tss?thread_id=35900
http://jroller.com/page/RickHigh?entry=facelets_aims_jsf_at_tapestry
http://raibledesigns.com/page/rd?anchor=taming_jsf_1_1
Personally I think it's a good thing JSF is competing with Tapestry as
it will make
both approaches better. At the moment however Tapestry is clearly in the
lead,
especially with the new stuff in 4.0 and it looks like the community is
growing rapidly.
We'll have to wait and see whether JSF will be as 'successful' as EJB
Entity Beans,
also a *standard*. To me lasting results for my customers are more
important
than standards per se.
-J.
Jacob Hookom wrote:
On 8/15/05, Ryan Wynn <rwynn <at> us.ibm.com> wrote:
It's quite obvious that Facelets can 'cast' a HTML element into a component, but
it handles it a little differently than Tapestry where everything stays strict
XML w/ namespaces. In addition, Facelet's JSFC attribute only handles half of
the equation, relying on a separate JSF-standard 'binding' attribute. Clay is
trying to to a straight copy of Tapestry, even going as far as using Tapestry's
parser.
Truthfully, I don't even like Tapestry's approach for 'casting' HTML elements in
the page as the 'standard'. It's not the point of Facelets, only a feature that
I added to appeal to the Tapestry users who complained about JSP as the reason
not to pursue JSF.
http://weblogs.java.net/blog/jhook/archive/2005/07/programmer_frie_1.html
Also, the project uses
applets quite extensively. From what I have read about Facelets I can
leverage JSF outside of a web container with Swing or SWT.
Facelets API is really simple and can be embeded into any kind of portlet
environment or even a desktop deployment. The point of Facelets is that
developers go through enough work writing applications that they shouldn't need
to worry about view-integration issues between JSP and JSF.
But how well does it work with Facelets? The tool integration is all
about the JSP view. Use a non-JSP view and most of the utility of the
tools dissappears.
I really could care less about tooling.
Thanks! And thanks to McKesson Provider Technologies for funding this
aspect of Tapestry 4.0.
Funny you keep on mentioning McKesson, I actually work in the med-surg division
in Minneapolis. The company is so big that no body knows anyone else or has
even heard of many of the other divisions and big enough to name drop.
As for the rest of JSF's stack... you should see some of the projects coming
from Oracle, JBoss, Apache, and Sun for use with JSF-- Facelets is only one
piece of the equation. At this point I really wish I could share more about
some of the new projects coming out, but just keep your eyes peeled for some
unbelieveable (standard) features that can make development *so* easy.
-- Jacob Hookom
Howard Lewis Ship <hlship <at> gmail.com> writes:
I have been using Tapestry 4.0 for 2 weeks now for portlet development and
I can say my experience has been very positive. I have found that my
tapestry portlets have come out much much cleaner than their JSF
counterparts.
I think the ability to inject pages and hivemend services
really makes for an elegant design. Not only that but the line precise
error reporting probably saved me hours of debugging (My mistakes in JSF
JSPs get wrapped in very obscure ClassCastExceptions in the logs).
However, I am tasked with choosing a framework for my client and although
Tapestry appeals to me it may not be right for this project. It seems to
me that with Facelets JSF is transforming more and more into Tapestry. JSF
tooling in WSAD (which is the project IDE) comes out of the box and is
further along than Spindle in the portlet arena.
Tapestry is so rich that, at first glance, Facelets does appear to
steal some of its better ideas. However, once you use Tapestry a bit
longer, you realize that the core strengths are not limited to the
templates. The injection model in 4.0 (which could be "faked" in
3.0), the extensibility via HiveMind, the JavaScript generation, the
localization support, and the whole approach at all levels to managing
state .... these are very much part of Tapestry too, and harder to
grasp immediately, and harder for JSF to replicate.
Is there anything fundamentally stopping JSF (the "standard" + all that
standard implies, e.g. it's not hard to hire a Struts expert) from
stealing the best parts of Tapestry (line precise error/templating to
start) and making me look like a fool for choosing Tapestry a couple years
from now?
Let's say everything you say might happen does come about. Well, then
your Tapestry skills will translate directly into JSF/Facelet skills,
and porting your application will be easy. Alternately, getting people
with JSF/Facelet skills will be easy, and they'll quickly adapt to the
"identical" Tapestry environment.
Thanks,
Ryan
=======================================
Ryan Wynn
Websphere Portal Developer
IBM Business Consulting Services - Public Sector
Reston Office: 703-668-2478
Cell: 703-622-1977
rwynn <at> us.ibm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Cumquat Information Technology
De Dreef 19
3706 BR Zeist
T +31 (0)30 - 6940490
F +31 (0)10 - 6940499
http://www.cumquat.nl
[EMAIL PROTECTED]
M +31 6 5 11 169 556
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
