"Geir Magnusson Jr." <[EMAIL PROTECTED]> writes:
> On 2/11/02 9:37 PM, "Daniel Rall" <[EMAIL PROTECTED]> wrote:
>
>> "Geir Magnusson Jr." <[EMAIL PROTECTED]> writes:
>>
>>> Well, I kind of liked it in the package I put it, but that's minor.
>>
>> It was already nested pretty deeply...and adapters are loaders.
>
> They are not, actually. They just look like loaders... :)
Okay -- as Jason pointed out, functionally they are Decorators.
> Yes, I was about to write another followup so it doesn't appear to be so
> cryptic :)
>
> First, I don't think actual implementations belong in Velocity proper -
> having the facility to do it does, but I think that the 'adapters'
> themselves will go in and out of fashion, and maintaining them in Velocity
> core is the wrong place - they would make a nice addition to -tools, in my
> opinion.
I agree with the spirit of what you're saying, but as far as the
ClasspathResourceLoader is concerned, I will *always* be using the
decorator which adds support multiple resource paths. It's rather a
bother to have to manage an additional dependency like
jakarta-velocity-tools to get this one class, which makes me think
that some decorators do belong in the core.
> Second, and here's the enhancement
>
> a) you can always do an adapter any time you want.. No support is needed.
>
> b) however, they are painful - the couple tightly the loader to the
> adapter above them, and worse, the loader(s) configuration(s) to the
> adapter, which IMHO sucks.
It's actually the Decorator which is coupled to the ResourceLoader
(rather than vice-versa), isn't it? I agree that it's not ideal, but
neither is it the end of the world (especially if most Decorators
reside in the tools repo). How can you possibly decorate if you don't
know what it is you're decorating? ;P
> So one solution is to add a 'pluggable template resolver', something that
> can be stuck in place and transforms each template request until one of the
> loaders resolves it. There are a couple of ways I can see this working -
> there are a few important things we prollie want to get in there, such as
> ensuring that the resource manager keeps control of the process, etc. Maybe
> some notion of iterator where the resource manager does something like
>
> Iterator it = resolver.getIterator( originalTemplateName );
> while ( it.hasNext() )
> {
> String name = it.next();
>
> // try and get a Resource for name...
>
> if (resource found)
> break;
> }
>
> That sort of thing.
>
> I can easily throw this together if you think this is better. The
> advantages to me are clear - you can write all sorts of wacky resolvers that
> don't have a care in the world about the underlying resource loaders...
This sounds like an improvement, Geir. Do you have time to take the
LoaderAdapter and PathMapAdapter Decorators and make them into
Resolvers?
Dan
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
