I've been using T4/4.1 for several years and have been quite pleased
with it. I've been using it with Hibernate, and while not perfect,
it's worked pretty well. We've found it much faster to embed a web
browser in our main app and do editing, queries and the like via
Tapestry than writing native code.
I have a new project to replace our aging billing system. I figured
this would be a great way to learn T5. So, I'm migrating me, not an
app. :-)
I was pondering posting this, but this thread sort of pushed me over
the top. Note that I don't disagree with anything Howard said.
However, this almost became "Why I almost dumped Tapestry entirely."
I'm writing this in order to solicit feedback and maybe help others.
I've been using Tomcat (now 6.0.20) and Eclipse (now 3.4.2) for quite
time time, and I'm very productive developing use them (and T4.1) I
think this is a pretty common development environment.
To get started in T5 for a fresh new app, my first thought was to
follow the tutorial at http://tapestry.apache.org/tapestry5.1/tutorial1/
.
Chapter 2 just plain didn't work for me. I think part of it is due to
Maven generally being extremely fragile and working less than half of
the time. However, even after working around that, you can't just
import the project into Eclipse. At least not under Eclipse 3.4.2.
No problem, I thought. Maven is annoying anyway. I'll just create a
Dynamic Web project (like I do for T4.1) and download the T5.1 binary
distribution. That's even worse. It comes with no README listing
dependencies or anything useful, and includes tons of libraries that
don't appear to be even needed. Tapestry failed to start up during
initialization. Why have a binary distro that doesn't work?
Back to Maven. After some googling, I found this article:
http://tapestry.formos.com/wiki/display/T5IDEINT/Eclipse+(including+Maven)
Shouldn't
this be included in the tutorial? Sadly, the tutorial is extremely
basic, but at least it works. (And is the only way I've found to
actually create a new project in Eclipse to date.)
Next, I tried Tapestry Jumpstart. After hours of configuration and
random errors (using Tomcat), it worked. However, it's so fragile and
klugy that I just can't see using it in production. I don't care
about
OpenEJB. I want just plain T5.1 and Hibernate. Plus running in a
remote tomcat sessions eliminates many of the developer productivity
benefits of T5 in the first place. One thing I liked about T4 was
that
I could deploy a WAR to a stock Tomcat install, and it would just
work. That won't happen with Jumpstart. Plus. it if takes 3 hours to
just get a working developer environment, why even bother?
Next up, AppFuse. It's only T4, but there is a Tapestry 5 add-on.
Sadly, AppFuse's T4 support is now broken due to a dependancy on
tapestry-flash that appears to be missing and following the
instructions on the AppFuse Tapestry 5 page doesn't work anymore
either, resulting in tons of missing resources.
So, since T5 doesn't appear to provide much in the way of
authentication / security (a very basic requirement for almost all
webapps), I started down the tapestry5-acegi approach. Of course,
that
doesn't work with T5.1. I managed to get it working and then upgraded
to tapestry-spring-security 2.1.0-SNAPSHOT. Still didn't work without
augmentation. (Thanks to maven for not updating the packages when I
switched to the snapshot, too. I had to delete the "nu" directory in
my ~/.m2 directory. One more reason Maven blows. It just doesn't do
what you want.)
I'd love to see more people use Tapestry, but after attempting a new
project, I'd feel embarrassed asking people to give Tapestry a look
at
this point. Heck, I'm thinking maybe sticking with T4.1 is the way to
go, despite all the benefits of T5. But, I really do want to start in
on T5 since I've loved using T4 for the last few years, and it does
seem to be a step forward.
I think its common to want to just get something working in order to
get a feel for the framework. Doing so in Tapestry, at least for me,
has been a waste of two days. I finally, on the third day, I have
something that appears to allow the tutorial to work with basic
security. I'm not sure if others have similar problems and just gave
up without comment, making other frameworks seem more popular?
Norman Franke
Answering Service for Directors, Inc.
www.myasd.com
On Jun 16, 2009, at 7:20 PM, Howard wrote:
I recently had an e-mail exchange with a Tapestry user; after
congratulating me on creating Tapestry, he went on with the
following
observation on his organization: The company I work at unfortunately
chose JSF for their big app. The reason was that Tapestry was
"brittle"
in the sense that, if one developer breaks something, on a page or a
service, very often the whole site won't come up because the initial
registry startup will fail. Or for example, if page A has a
pagelink to
page B, and page B is broken, then page A won't render. While I
agree
that we shouldn't ship unless the whole app is working, this is a
thousands of pages big app with hundreds of mediocre (as in likely
to
break things) developers. They'd rather have 80% of the thing
working
than nothing at all. I never thought of this for my own projects,
and
haven't had the time to examine the truth of their claims. What's
your
take?
I provided the following response:
Early failures are absolutely, 100%, the only path towards code
quality. You may have heard the phrase "no broken windows" (see "The
Tipping Point" by Malcom Gladwell for more details) but the short
form
is that when errors go uncorrected (whether they are broken
windows in
an abandoned building, or broken code in an application) they tend
to
multiply quite rapidly.
The things that will "break" a link from page A to page B are
substantial problems such as invalid templates, references to
unknown
properties or components, or compile errors in the page B class ...
things that no other developer should ever see when page B's
developer
is working and checking in code. That is, problems that should
never be
checked into trunk, but instead kept in a local workspace or a
private
branch.
An organization that thinks that fail early is a problem is an
organization that isn't prepared to develop a large application in
any
technology. The image I'm getting is one where there is no build
server, no continuous integration, at best CVS for source code
management (or possibly one of those "shared directory"
monstrosities) .... i.e., a chaotic environment where errors are
allowed to be checked in to the trunk and can go unnoticed for some
time.
The solution to coding errors in pages or components is not to wait
until your testers (or end users) find the bugs, but to identify and
fix the bugs early. That's called "engineering discipline" and the
reality is that even self-professed "mediocre" developers can do it.
Tapestry helps because it fails early and has great exception
reporting
to guide you right the problem so that you can fix it.
Another factor here is enforced helplessness. If only Fred
understands
page B and he's out when it's broken, then all development stops
waiting for Fred to get back. I hit this problem myself, years ago
working on a large Struts application (those words give me the
heebie
jeebies now!). We had lots of code, a fragile and slow build
process,
and many little code "fiefdoms". I spent too much wasted time
twiddling
my thumbs.
Nobody should "own the code"; if page B is is broken, Julie (who
normally develops page A) should be free to fix it. Julie will
need to
understand the page B code well enough to fix it, but also you
need an
overall environment with shared source, no repository locks (that
is,
nothing that says "Only Fred can change this file"), and no
management
PHB's getting in the way. Pair programming is the best way for
Fred and
Julie to share knowledge so that they can understand each other's
code.
Even if pairing occurs only part time, it's very effective at
knowledge
transfer as well as ordinary coding.
The idea that "mediocre" developers should use JSF as it is more
tolerant of errors is absurd! Tapestry 5 is designed to improve
productivity for all developers, by streamlining, simplifying, being
smart and being concise ... not to mention live class reloading and
best-of-breed exception reporting, which makes it fast to identify
and
fix those errors.
If your doctor tells you to eat less red meat, that doesn't mean you
should switch to a diet of fried chicken three meals a day!
Likewise,
if you have concerns with code quality from your developers, you
should
not switch to a less agile, more code-intensive, less supportive
development model and hope to catch all the bugs in QA. Sweeping
problems under the rug is never a winning strategy.
Coming down off my soap box, I should also add that Tapestry 5.1
works
a little bit differently than 5.0 in this respect, so it does (in
fact)
defer more of the page loading and validation until a link is
actually
clicked. This is more for performance reasons than to shield
developers
from application problems. Even in 5.0, the loading and validation
was
the "reach" from page A to pages explicitly referenced (usually via
PageLink during the rendering of page A), so it's a highly unlikely
case that a single error in a 1000 page application will keep the
application from starting up, unless the start page of the
application
links to all 999 other pages.
Re-reading the above post I can't emphasize enough: you can't ignore
quality problems. Quality problems lead to development failures,
schedule slips, missing functionality, low morale and high turnover.
Saying "we don't have time to fix the quality problem first" is to
ignore the the second law of Thermodynamics. You are expecting a
miracle, literally writing it into your project plan.
Formos addresses this issue two ways: First, we use Scrum and
deliver
on (typically) 4 week cycles. Thus we set real deadlines and have a
constant check on quality (we're providing working code
constantly). We
don't even try to predict what we'll be doing six months or two
years
from now, we just deliver a steady, manageable stream of software.
Secondly, Formos uses Tapestry because of all the reasons that the
anonymous developer's organization rejected it, and for many, many
more
reasons besides.
--
Posted By Howard to Tapestry Central at 6/16/2009 03:45:00 PM
