[Tapestry-developer] Consistency vs. Ease of Adoption

Thu, 10 Oct 2002 04:53:52 -0700

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.
 

Reply via email to