I didn't read my mail on this list for a minute so I missed the flame war...
Here's my two cents.
Is Tapestry hard to learn?
~~~~~~~~~~~~~~~~~~~~~~~~~~
YES. But all frameworks are hard to learn.
I spent a couple of weeks trying different frameworks. After reading
up on a bunch, I gave both Barracuda and Tapestry a try. Barracuda had
a longer learning curve, largely because it was not as easy to get up
and running out of the box. It took me a week to figure out how to do
what I needed to do with Tapestry, after that I could build my whole
application very quickly.
We had a PHP guy on staff at the time who learned JSP/Struts while here
(JSP/Struts learning curve seemed to be on the order of months, not
easy to pick up but now there are book I understand). After more than
a month with Tapestry, he still didn't really get it. I take this as
evidence that it is hard to shift from a scripty type system to Tapestry,
but JSP/Struts is no piece of cake either.
I think the solution is better documentation, and more importantly
simpler examples - a cookbook type approach. This may be impossible
given Tapestry's rate of development since new features are coming
out so quickly. There's not a lot of motivation to write good
ducmentation when you know it has a shelf-life of minus five
minutes (already obsolete by the time you write it).
Is Tapestry cumbersome once you've grokked it?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sort of. IMO, Tapestry makes hard things easy and easy
things hard.
You get used to creating the .html, .page, and .java
files but I find I'm often typing stuff that the framework could
figure out for me. Something on the lines of anonymous components
would be nice (for me). For instance, I don't think you
should ever have to declare an Insert component - you should
be able to specify a property-path in the <span> tag and
just display the stuff. I agree with others that this opens
up a Pandora's box which may lead to putting scripting in
the HTML again. Maybe best to keep the lid on that - there's
already a lot of players in that field.
The consensus on this list seems to be, Spindle is the solution
to the drudgery aspect of Tapestry.
I'm not too comfortable with that line of thinking.
Hiding a cumbersome development process behind great tools
is more the Microsoft approach and it's expensive to maintain.
If we're saying you need Spindle to make Tapestry usable, then
we're saying you need to use Eclipse too. Switching IDEs is
a biggish investment for a developer to make. I've given Eclipse a
serious try (3 months) and IMO it's just not that great an IDE.
Also, Geoff has a hard time keeping up with new Tapestry versions
and new Eclipse versions at the same time - he has a double coupling
there which is not fun. I've never been able to use Spindle so far
because either I needed features from a newer release of Tapestry
than Spindle supported, or there were bugs in Spindle or Eclipse
that prevented my use of it. Right now I can't even run Eclipse on
my linux box because the 2.0 stream depends on a new version of
the GTK and I need to install at least a dozen RPMS to solve that!
OTOH, I've found developing for Tapestry to be not _that_ painful
without Spindle. IDEs are starting to come out with good XML
editors (the early access release of Intellij IDEA does, anyway).
A DTD-aware XML editor makes developing for Tapestry _much_
easier. Maybe Tapestry should try to optimize for this time of
environment: java IDEs with good XML support. Then you don't
need plugins for Eclipse, IDEA, JBuilder, Forte, NetBeans,
(emacs!,) ...
<aside>
Something that would be nice would be the capability to set
some static parameters on your Page classes in the .jwc files.
I basically have an EditProfilePage and a ListProfilesPage. These pages
need to be have a couple of things set on the - the EJB that
they are using, the type of profile that they are managing.
For each .jwc I need to create a new subclass of one of
these pages. All the subclass does is sets these two string
parameters. I'd like to do that in the .jwc and not need the
subclass. This would make for a more complex caching algorithm for
the pages.
</aside>
