Well, the point is to support static HTML files as well as component templates, so a different extension is pretty critical to that.
Eventually want to support trivial pages without a Java class. On 9/26/07, D&J Gredler <[EMAIL PROTECTED]> wrote: > > Agree on #2 and #3, disagree mildly on #1. If there's a concensus on #1 > though, I don't have a problem with it. > > Of course, we could compromise: rather than Tapestry Markup Language or > HyperText Markup Language we could have Hyper Tapestry Markup Language, or > HTML ;-) > > Take care, > > Daniel > > > On 9/22/07, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > > > 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 > > > > > > -- > Daniel Gredler > http://daniel.gredler.net/ > -- Howard M. Lewis Ship Partner and Senior Architect at Feature50 Creator Apache Tapestry and Apache HiveMind
