On 2/11/02 9:37 PM, "Daniel Rall" <[EMAIL PROTECTED]> wrote:
> "Geir Magnusson Jr." <[EMAIL PROTECTED]> writes:
>
>> On 2/11/02 8:37 PM, "Daniel Rall" <[EMAIL PROTECTED]> wrote:
>>> So the adapter wraps the resource loader. Formalizing the concept
>>> of an adaptive loader is it good idea. It draws on the existing
>>> Velocity configuraiton vocabulary and extends it, which is much
>>> better than introducing an entirely new entity (the new addition
>>> won't be as foreign to developers). I've gone ahead and checked in
>>> the code as two classes, LoaderAdapter and PathMapAdapter, which
>>> are two halves of the code seen below. I'm thinking that
>>> LoaderAdapter might be better named either ResourceLoaderAdapter or
>>> AdaptiveResourceLoader. Thoughts?
>>
>> 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... :)
>> What I really was getting at was to do something completely
>> different than this - but wanted to test the waters to see if this
>> would work for you.
>
> This works really well for me. What was it that you were getting at,
> maybe that would work even better? ;-)
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.
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.
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...
Geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
The question is : What is a Mahnamahna?
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
