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+Mave
n) 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
