Also, the jwcid tags smacked too much of the 'tal:' syntax in Zope, which I've learned has many flaws in it which hamper regular development, despite it's other benefits. Again, you find yourself jamming programming code in non-semantic tags, even if you can later strip it out with more 'tal:'s. Similarly, Erik demonstrated how the page opened with a 'body' tag, which was then replaced with all the tags usually outside the body tag, like html, head, meta, etc., which to me seems like a dangerous tool which would allow for too many opportunities to make the code way too confusing. The programming should not be allowed to operate outside the tags which are meant to be templated.

At one point in the presentation, the there was some HTML with a tr tag, which should have been a td tag. Tapestry quietly replaced it with a td tag. This could potentially create an unmaintainable set of files, because it fails to encourage the programmers and producers to use good HTML. Say someone (not the original author) needed to edit this code, and wanted to put something on a tr tag. Well, there's one already there, so they add in the code and the page breaks because it has things which belong an the tr and on the td in the same tag. Now, since it's mixed, finding that error is more difficult.

I agree with Brennan that a great way to create a templating system would be to have it based on 'id' tags. Erik, I would like to hear what the issues that have come up with those might be. In the end, I think a template which has nothing but regular HTML that a designer/producer can manipulate would be the best method to have a presentation layer on top of business logic. Having been exposed to agency settings and seeing that designers and HTML producers usually don't want to know anything about the programming, divorcing them entirely from it is the best way to prevent mistakes, or the inevitable finger-pointing which comes up when a programmer and producer both work on a page and it doesn't work.

I would go one step further from Brennan, too. There's no need to use divs or spans exclusively. The DOM allows you to attach IDs to any element HTML. I could see how the table object in Tapestry could be applied directly to a table with an ID in HTML. In fact, it could even be applied to a tbody element, allowing the header information to be separate from the 'processed' output, if need be.

Over the last week, I've come up with this basic structure: An HTML page is created on the site. When it is called, the server searches for something like the Tapestry .page file or a Java class with the same name (say 'index.html' and 'index.class'. If found, the HTML is run through an XML parser and provided to the .class or .page file, where it could be traversed by the programmer to get to the IDs that need to be managed, leaving the rest of it alone. Information which needed to be applied to the whole page could be put in something like the applet init method (this is one place where the tal: tags in Zope page templates fall apart). There could still be a global file that would be used to maintain things like navigation, footers, breadcrumbs, etc.

For all that I have read about the evolution of HTML 3.1 to modern XHTML I do not recall anything about it simplifying the process of integrating dynamic content within HTML markup in mind. That seems like an oversight. I suppose breaking up the structure inside XHTML and exporting style and layout to CSS was the first step.

But it seems that with all of the turbulance of web standards there are now many different branches of thought which have lead to diverse techniques of web page creation. Many are still quite reliant on using TABLE tags for layout while very few seem able to promise the DIV/CSS layouts described by Jeffery Zeldman. His approach which is where XHTML is supposed to be heading lends itself to very different templating solutions.

As for the session support in Tapestry there is a great deal of value for many developers who need it but for a long time I had to rely on other means due to a load balanced server cluster which did not have any way of distributing a session across the cluster. So we developed other techniques which were sufficient and actually only took a single Class to support the solution. I always prefer the minimalist approach.

The JSF transition away from the existing JSP/JSTL approach a shame because I felt they were going down the right path. Now JSF seems like the event-based challenger to ASP.NET. And as I learn more about how classic ASP which was upgraded from a linear solution to the event-driven ASP.NET I see the very same could be done with JSPs instead of scrapping it all for JSF. Smart meta frameworks like Tapestry can layer themselves right on top of the solid base that Servlets already provide. To me the appeal of JSTL was that I could write real Java code with an well-known interface and simply configure the web application to use them. It is a simple an elegant approach which the current version of JSF has abandoned.

But now you got me going and I could keep writing on this all night, so I will just stop here. I am sure I will have much more blog entries along these lines as I learn more about ASP.NET and dig into more templating solutions in both Java and .NET. But I will be sure to give Tapestry another look. I am sure there are many hidden gems in there which make it very worthwhile. I would be very interested in decoupling some of those powerful gems so that other templating engines could leverage them and share the work in improving those components.

There is way more involved with Tapestry than a simple SSI-like mechanism. These are true components that can interoperate with the page, visit state, and much more.

As Howard mentioned - OGNL isn't as bad as you make it sound. In fact, having light-weight expressions makes Tapestry very easy to work with and evolve applications with.

What I have been doing for years is leveraging the power of the Apache server to allow Server-Side Includes (SSI) to include content inside a template. I create a site with a static template then extract bits like the header, navigation and footer into fragment files. And since the SSIs also allow for including dynamic content I pull in reference to Perl scripts which have been tuned with mod_perl. It is actually a very powerful combination. it just so happens that Java provide a much richer and robust framework with the help of the Apache/Jakarta project. But like I described, the SSI directives simply acted as markers and did not have to pass along any arguments. Everything I needed could be extracted from the query string or the path info in the URL. It seems that some template engines add a bundle of features which may not be necessary.

OGNL frees you from the compile-build-deploy cycle ... using OGNL to connect your Java code to your HTML components is just plain easy.

What's hard to get across in a short presentation like mine or Erik's is all the things Tapestry does that go far, far beyond the templating angle. There's a huge amount of state management occuring for you when you use Tapestry. Further, nearly all of your wishlist are things already in Tapestry.