On 2/12/02 10:13 PM, "Daniel Rall" <[EMAIL PROTECTED]> wrote:
> "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.
Indeed.
>
>> 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.
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.
>
>> 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?
Sigh. The point was that they do entangle - you have to mix things up.
> 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
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.
This just doesn't make sense to me.
>
>> 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?
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...
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"He who throws mud only loses ground." - Fat Albert
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
