I'm always up for more help. The Wiki was set up as a good place for these discussions. Tapestry is positioned very well for the refactorings that Kenny is suggesting (except for insufficient unit tests).
I think his issue was that the logic that locates (localized) specifications is too tightly coupled with the code that loads the specifications. I don't see why these could not be refactored easily enough. The fact that Tapestry uses interfaces makes it much easier, as you can use a Decorator pattern ... that is, a new implementation if ITemplateSource that handles specific cases, and passes on other cases to an instance of DefaultTemplateSource. -- [EMAIL PROTECTED] http://tapestry.sf.net > > 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: | > | | tapestry-developer- [EMAIL PROTECTED]| > | | eforge.net | > | | | > | | | > | | 07/09/2002 08:19 AM | > | | | > |--------+--------------------------------------------- -> > > >-------------------------------------------------------- ----------------------- > -------------------| > | > | > | To: 'Mind Bridge' <[EMAIL PROTECTED]> > | > | cc: "'tapestry- [EMAIL PROTECTED]'" > | > | <tapestry- [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 ------------------------------------------------------- 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
