----- Original Message -----
Sent: Thursday, October 10, 2002 8:24
AM
Subject: [Tapestry-developer] Consistency
vs. Ease of Adoption
I'm thinking there is room to simplify some
aspects of Tapestry.
Imagine if Tapestry scanned just the root
directory of the web application context (not sure how to do this, but assume
it can be done).
Each .html it finds is "wrapped" as a Tapestry
page.
The page has a standard HTML template, but
there's no specification, so you can only use anonymous
components.
We add some kind of directive so that the page's
class can be specified. Perhaps another magic jwcid, i.e.,
jwcid="$class=foo.bar.Baz$"
or
<span jwcid="$page$"
classname="foo.bar.Baz"/>
You don't need .application file
(initially).
I'd call this "Tapestry RAD". You get to
see HTML templates and simple components. You can use named components,
libraries or anything else that's fancy. You only use the default,
SimpleEngine, and the visit class is defined in web.xml, not the
.application.
Eventually, you start needing more sophisticated
pages. You then create a .application and .pages, normally.
There's the question of whether you can support Tapestry RAD pages and
traditional Tapestry pages.
I'd bill "Tapestry RAD" as something very
limited, something only used by beginning developers or during initial
prototyping. Traditional Tapestry development, i.e, "Tapestry POWER" (or
something) is where you end up ... when you want to use advanced features like
assets, helper beans, localized templates (very rare, BTW).
Components and pages in libraries will have to be
done using traditional Tapestry.
"Tapestry RAD" would still be real Model 2 style
development but very fast setup.
Anyway, after a couple of days working through
Marc's rantings, this is what it boils down to.
Problems:
Generating that list of HTML pages may be
servlet-container specific. Perhaps we don't generate a list, we just search
for the page as needed.
There's still some class-loader issues to deal
with. May need different versions of ApplicationServlet that adapt
Tapestry to different containers. Hqave to find out if major containers
(Jetty, Resin, Tomcat, WebLogic, WebSphere) set the Thread's context class
loader or not.
Philosophy: There's now two ways of doing
the same thing. Marc embraces this, but there's general resistance to it
elsewhere. There may be ugly interactions between the two models.
Many people *will* misuse it because it is simple startup (you must always
throw away the first prototype, but most don't).
I've seen some
responses that say Tapestry simply isn't for the masses, but I just don't buy
it. At the core, Tapestry is simpler than other frameworks and more
powerful, it should be much more widely adopted. I buy into the "shark"
theory ... keep swimming or die, Tapestry must extend its range or it will
never escape niche status and will eventually die off. Tapestry
RAD could be the thing that gets Tapestry in front of a lot more
eyeballs.
