Despite being one of those who recommended configurable, alternate
extensions to allow for different tooling on the dev side, I have to
agree with this proposal. Most of my tooling is eclipse anyway, and
at least having a separate non-".html" one is better, given that .tml
files would be well-formed xml - something that html itself is not. I
especially like the move of templates to the root of the context and
the filtering of .tml files. While I prefer having configurable tag
endings, this is a sane middle path I can deal with.
+1 on this proposal.
Christian.
On 22-Sep-07, at 7:29 PM, Howard Lewis Ship 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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
