I've been making some progress towards the goals of "Tapestry Lite".
Obviously, the new ApplicationServlet is a good start. That's not a terrible idea, that there should be a default location for the application specification. I'm also thinking that the 1.4 versions of the specifications (sorry Geoff) will allow the class names for the engine, page and component to be omitted (defaulting to SimpleEngine, BasePage and BaseComponent, respectively). I'm a bit more nervous about the idea of scanning for .pages. First off, it represents a shift in Tapestry from storing page (and component) specifications in the classpath to storing them in the web application context (i.e., alongside static HTML and assets). Also, I'm not aware of a completely portable way to "scan" for files ... you would need to do a bit of work to down cast ClassLoader to specific implementations that had the necessary methods. I'm not even sure which ClassLoader methods I'd need ... probably have to get to URLClassLoader, query the URLs, work from there. Messy (but doable). Anyway, where I'm headed now is Tapestry Lite, with big flaming warning signs, but - You can put your HTML files in the web app context (at the root) - An "implicit" specification will be generated from such HTML files - The HTML file can specify the Java page class - You can define components (ids, types and bindings) in the HTML (I call these "implcit components", vs. the "declared components" of traditional Tapestry) - You don't need an app specification (initially) - You can mix and match Tapestry Lite with traditional Tapestry, so when a page becomes too complex to be implicit, you can create a .page for it and register the .page in the .application So, for all of Marc's infuriating lack of manners, I'm trying to reach the goals he suggested ... the ability to get up and running quickly. Which is a good goal, it will keep the "non-rock-stars" who try Tapestry around long enough to get hooked. Also, I think (in the long run) a lot of components are going to "go implicit". Components that generally don't take formal parameters (such as Body) can simply be <body jwcid="@Body"> and be done with it. Likewise, most Inserts and Conditional components can be implicit. The downside to implciit components is a) Back to JSP problems when you have multiple localized templates (though mostly localization is done through strings now) b) How to interpret the attributes in the HTML template: as OGNL expressions or a static strings? (b) is the vexing problem ... to the point that I'm thinking that to maintain sanity, I may have to introduce (<binding name=".." expression=".."/> into the HTML template to support implicit components. Or I may have attributes that exactly match a formal parameter be treated as OGNL expressions, and other attributes treated as static strings (as all informal parameters are today). ----- Original Message ----- From: "Sacha Labourey" <[EMAIL PROTECTED]> To: "Tapestry-Developer ML" <[EMAIL PROTECTED]> Sent: Thursday, October 24, 2002 2:28 PM Subject: [Tapestry-developer] Suggestions for Tapestry (long post) > Hello, > > I've read the numerous posts about simplifying access to Tapestry for simple > projects. I'd like to contribute some constructive ideas on this topic > (without generating to much heat though, if that's possible...) > > First of all, please be sure that I really understand why some people are > affraid loosing Tapestry's strength, typing, etc.: all the ideas I will > propose are lead by two goals: > - to simplify Tapestry's use for small projects (or for prototypes) > - to work more easily with "verbose" web sites (I will explain that below) > > BTW, sorry for the long post (it is not intended to test DB2's CLOBs > @sf.net) > > > SMALL PROJECTS > ============== > While I agree that the overhead of a few .application and .page files is > negligible for most projects, I also think that this overhead is not really > necessary (and annoying) for really quick prototyping. > > We could very easily imagine to reduce this overhead without sacrifying the > current (advised) behaviour. I start... > > 1�) ApplicationServlet > Today, Howard commited a change so that the servlet definition could include > the path/name of the xxx.application file and thus, for simple applications, > it is not necessary to implement a new servlet just to give this > information. I think that is a really good thing. > > Nevertheless, I think we should go further and that by default, > ApplicationServlet should use, for its > "net.sf.tapestry.application-specification" parameter, the value > "/default.application" (or any other name) > > And it would answer Howard's wink saying "Seems like its just as much typing > as creating a subclass". ;) > > As EJBs have a default META-INF/ejb-jar.xml file, I don't see what is > terrifying about having a default .application name (that you can override!) > > > > 2�) xxx.application file > The xxx.application file mainly defines an application name, an engine > class, a visit object and a set of pages. > > Most of the time, the most cumbersome thing to do is to list all pages in a > set of <page> attributes. Consequently, why not add a new tag such as > <pages> i.e. > > <!-- explicit method --> > <page name="Home" specification-path="/tutorial/hangman/Home.page"/> > <!-- NEW implicit method --> > <pages dir="/com/here/foo" matches="*.page" recursive="yes" /> > > You will ask me "what about the page name now?!?". Well, we could simply > define it in the xxx.page file directly i.e. > > <page-specification class="tutorial.hangman.Home" page-name="Home" > > ^^^^^^^^^^ > or use the file name directly (but I am sure you won't like it) ;) > > This way, the xxx.application file can be very simply while making xxx.pages > only slightly more complex. > > To recursivly find all *.pages file, ServletContext.getResourcePaths () can > be used. > > > > 3�) Totally removing very simple xxx.application files > For very simple prototypes, the xxx.application file doesn't contain any > critical information: > app name (not critical, can be defaulted), engine class (SimpleEngine), > visit object (not necessary). > > Only the default set of pages is important. Thus, when no > /default.application file is present, we could default to an implicit > declaration such as: > > <application name="Default" > engine-class="net.sf.tapestry.engine.SimpleEngine"> > <pages dir="/" matches="*.page" recursive="yes" /> > </application> > > I am sure this is exactly the kind of behaviour we would implicitly expect > i.e.: I just gave you a few xxx.page files (and their associated xxx.html > file), just use them! Otherwise, it is a little like if you gave your VISA > card to a clerk and the guy would tell you "What do you expect me to do with > it?" (it is obvious: I just want to pay!) It is the same here: I give you a > WAR containing some *.page files, just use them! > > > ==> Conclusion for this first part: > =================================== > > With these modifications, nothing of the current behaviour is changed. At > the same time, let's see a few scenaris of what could be achieved. > > S1: > you could have a simple tapestry application consisting only of this: > /a.page > /a.html > or this: > /my/app/a.page > /my/app/a.html > > S2: > If you want to change some info such as setting a visit page: > /default.application > /my/app/a.page > /my/app/a.html > > both examples don't need a specific servlet parameters and the second > example defaults to /default.application > > For people that don't want these defaults, we can imagine to have a JVM > property (such as "net.sf.tapestry.strict-mode") that can be set to > prohibit/avoid these implicit behaviours. > > > > SECOND PART: VERBOSE SITES > ========================== > The second kind of suggestions concern what could be called "verbose" web > site. > > What Tapestry is very good at is to deal with user interaction. > Specifically, interaction with forms is really GREAT. Nevertheless, imagine > that what you have, in some part of your web site, is a huge set of > presentation pages such as a full set of documentation (Tapestry doco for > example). In this case, Tapestry is really cumbersome to use. > > These (verbose) web sites would still benefit from Tapestry (to mimic > sitemesh behaviour, extract user information from the session in a component > and display it at the top of the page for example, etc.) but writing an > *identical* xxx.page file for *each* xxx.html page is really, really > frustrating. > > My suggestion would be to allow many html (sub-)pages to be linked to a > single xxx.page definition. These html would be required to follow some > strict naming conventions such as (let's say we have a "xxx.page" file): > > xxx.html (default page) > info.xxx.html > setup.xxx.html > ... > > Then, when referencing pages, it would be possible to give a PAGE name (as > now) AND an optional name such as "Chapter", "sub-page" or "view". For > example: > > <component id="setup" type="PageLink"> > <static-binding name="page">xxx</static-binding> > <static-binding name="view">setup</static-binding> <!-- NEW > PARAMETER --> > </component> > > Thus, a whole set of pages could be linked to a single xxx.page file. At the > same time, the localization features could still work (by using the same > current naming scheme) > > Consequently, part of web sites that only deal with displaying static > information + displaying some session info would be very easy to write. > > That's all for today ;) > > I would be glad to hear your constructive comments. Cheers, > > > > Sacha > > > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en > _______________________________________________ > Tapestry-developer mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/tapestry-developer ------------------------------------------------------- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en _______________________________________________ Tapestry-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/tapestry-developer
