Why the templates should end with "html"? Cause we have people that are
absolutely novices to technical details but they are smart enough to change
some html. With "html"-templates it is easier to communicate the special
template-parts (they see its html even from file-name) and they don't have
to reconfigure their tools to handle "tml" correctly.
Why it should be interchangeable? Cause while searching for an easy way to
change the extension, I've found some discussion about the default extension
in the mailing-list. I remember a guy who wished the extension would be
"tpl" for some reason. Personally I prefer the wicket-approach of simply
leaving "html" as template-extension. I think tapestry is very good in
enforcing best practises but some decisions are either too early or too hard
like the default-template extension. There simply should be a way to change
naming-standard without rewriting template-loading. The code-example
provided by me works in my specific case. Some functionality like that (or a
TemplateNameProvider-Interface) should go to the core.
Why a fallback? It is the most straight forward way to implement that
feature in the given codebase without scarifying compatibility.
Mario
2009/4/5 Carl Crowder <carl.crow...@taptu.com>
> Why, out of curiosity?
>
>
> Mario Rabe wrote:
>
>> Why is it so hard to change the default-template extension? I really want
>> the templates to end with "html"! The I saw the template-extension is
>> defined as a constant. It is even inlined in classes.
>> ComponentTemplateSource#baseResourceForModel is private so there is no
>> override. Beside that ComponentTemplateSource is final. Similar problems
>> with PageTemplateLocator.
>>
>> So to change the extension from "tml" to "html" I have to copy 2 internal
>> classes, change them slightly and override the internal services.
>>
>> Thats not very tapestry in my oppinion. There should be a symbol in the
>> core
>> which defines an alternative extension for templates. If a template could
>> not be found using the default-extension then the alternative extension is
>> checked before loading fails. Code could look like:
>>
>> Resource res =
>>
>> model.getBaseResource().withExtension(InternalConstants.TEMPLATE_EXTENSION);
>> if(res.toURL()!=null){
>> return res;
>> }
>> return model.getBaseResource().withExtension(altenativeExtension);
>>
>> Maybe there is a more effective way to provide such a feature using
>> module-scopes. What do you think about it?
>>
>> Mario
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
