It is at this point that most evolution of the framework loses its
momentum. Sounds like Kenny has a need and has a viable idea for an
alternate design. Too often, such an alternative is not offered in
sufficient detail to discuss or is not offered at all.
I think it should be a common community paradigm (in a FAQ) that new
ideas/gripes such as this are often legitimate and we would like to discuss
alternatives...just waiting for someone to put together the proposal. Maybe
more folks don't do this because they don't understand the underpinnings of
the framework. Now that we have a Wiki, we can do a better job of
annotating the framework as a community.
Let's keep these ideas from either dying or ending up in Howard's lap by
default. Kenny, I would encourage you to propose this design change idea in
detail (though you've already gone further than most)...attach a graphic of
a new way for things to fit together...or just describe it in detail...if
you don't quite get it all, no sweat...folks will help. Keep in mind that
not everyone on the list is completely familiar with all the guts that you
are reading through, so some annotation might get you more feedback. It's
just that many of us do not have significant time we can devote to this
outside of our daily work.
-Christian
|--------+---------------------------------------------->
| | "MacLeod, Kenny" |
| | <[EMAIL PROTECTED]> |
| | Sent by: |
| | [EMAIL PROTECTED]|
| | eforge.net |
| | |
| | |
| | 07/09/2002 08:19 AM |
| | |
|--------+---------------------------------------------->
>--------------------------------------------------------------------------------------------------|
|
|
| To: 'Mind Bridge' <[EMAIL PROTECTED]>
|
| cc: "'[EMAIL PROTECTED]'"
|
| <[EMAIL PROTECTED]>
|
| Subject: RE: [Tapestry-developer] Seperation of java, jwc and html files
|
|
|
>--------------------------------------------------------------------------------------------------|
Hi there,
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
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Stuff, things, and much much more.
http://thinkgeek.com/sf
_______________________________________________
Tapestry-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/tapestry-developer
