On 2/13/02 2:07 PM, "Daniel Rall" <[EMAIL PROTECTED]> wrote:
> "Geir Magnusson Jr." <[EMAIL PROTECTED]> writes: > >> I don't agree. I agree that we should build in support for this, but not >> with including various ones in the core. >> >> Why? Because to me, this is application functionality... Your application >> is designed with this mechanism in mind. > > Any enterprise-ready application which has a UI *must* be brand-able. > Experience has taught me that when using a templating system like > Velocity or WebMacro, this is most easily accomplished via the use of > template search paths. > > Velocity is an enterprise-ready templating system, and I expect it to > have support for multiple search paths available in the core which I > can activate at the flick of a switch. When I went to do just that > for Eyebrowse (after switching from file-based to classpath-based > template loading to make deployment easier), I was very surprised to > find this functionality absent. And velocity isn't an application. And there are different approaches to branding.... > >> Because it now means your configuration of your loader is now mixed up with >> the decorator - so if you were going to programmatically set this up, you >> can't just configure your loaders and then configure the decorators. You >> need to first figure out if there will be decorators, then take the loader >> information (and pray there isn't more than one) and mangle that into the >> decorator config. > > We'll have to agree to disagree here. Loaders need know nothing about > decorators (though the opposite is not at all true). I never said that, so we won't "agree to disagree". In the case I outlined, you the programmer have to figure out what loader someone wants to use, then configure the decorator to use it. This entanglement doesn't make sense to me. They should be independent. >> This just doesn't make sense to me. > > Which is why I'm willing to try out your proposal... Excellent > >> I think it is an improvement, and that means that you can plug in the >> resolver (or resolver chains - that would be cool) w/o caring about >> how/where/which is being used for the loader. >> >> What I think I will do if no one objects (and I will post a separate message >> so people see it) is do a 1.3 release to get the current stable codebase out >> as a release, and then do this change. I was working on it last night, and >> will need some changes to resourcing... > > +1. How about removing the Decorators currently in CVS until after > 1.3 is branched, at which time you can re-add them Resolvers? Yep - will do. > > Dan > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting You're going to end up getting pissed at your software anyway, so you might as well not pay for it. Try Open Source. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
