In the back of my mind, I've been pondering changing the template extension for a while. This has flared up on the Tapestry user mailing list.
I would propose: 1) Use the extension ".tml" (Tapestry Markup Language) for Tapestry templates, rather than ".html". This reflects the goal of using Tapestry to serve many kinds of markup, not just HTML (and XHTML). 2) Move web context templates from WEB-INF to / (root). This will allow relative paths to resources (images, etc.), much as in Tapestry 4. 3) Extend the TapestryFilter to block access to ".tml" files from the client. This addresses security concerns related to external users gaining access to raw templates (much as we are careful to block access to Java .class files via /asset). I think that in this day and age, any credible text editor will not have a problem mapping the extension ".tml" to XML or XHTML. I think moving the files to the root, much like a JSP, is ultimately a good thing ... as long as there is no way for such a file to be accessed by the end user. (We would be careful, for instance, to check caselessly for the ".tml" markup). I'm very strongly opposed to allowing different extensions in some configurable manner. Just as Geoff why this is a bad idea :-). Seriously, as invisible as the instrumentation is, it is still an XML based markup with namespaces, even if the end-application is served up as SGML. There are many ambiguities in the T4 code around this, which again, makes it harder to know what the framework does in a given circumstance, or whether it is doing the correct thing. Thoughts? Unless there is a credible amount of opposition, this is something I'd like to take care of in the next few days, for release in 5.0.6. And I want to do 5.0.6 about as soon as I add in a DateInput component and fix a few more bugs. Separate discussion. -- Howard M. Lewis Ship Partner and Senior Architect at Feature50 Creator Apache Tapestry and Apache HiveMind
