In any case, if you still want to get the templates from somewhere else, you can override the method 'createTemplateSource()' in your Engine and return your own implementation of the ITemplateSource interface. That will allow you to define your own logic for locating the templates of the components (you can even get them from a database if you wish to).
You can find the default implementation of ITemplateSource in net.sf.tapestry.engine.DefaultTemplateSource. Please keep in mind that if you care about preserving the template localization mechanism, you should get templates depending on the supplied locale (e.g. Template_en_US.html, if present; then Template_en.html, etc).
Looking the source code, it seems to me that the mechanism for locating the template resource is too tightly coupled with other functionality. If I were to re-implement ITemplateSource, I'd have to duplicate a lot of work.
Alternatively, if I were to provide my own implemention of IResourceResolver, and pass that to the constructor of DefaultTemplateSource, then would that do the job?
I think this problem, combined with the similar problem of locating the application and component specifications, is my main gripe at the moment. The idea that specs and templates should be in the classpath may be good practice in some situations, but it shouldn't be assumed that this is how Tapestry will always be used.
I'd very much like to see a properly abstracted mechanism for locating ANY resource used by the framework, be it specifications or templates or assets. For now, I can dig through the source and override when appropriate and possible (there are a few too many private methods in the source, perhaps they should be protected?).
cheers
kenny
