You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Geir Magnusson Jr." <ge...@optonline.net> on 2002/02/12 03:27:59 UTC
Re: Two Birds : WAS
"Re: [PROPOSAL] Multipath ClasspathResourceLoader"AND "i18n"
On 2/11/02 8:37 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> "Geir Magnusson Jr." <ge...@optonline.net> writes:
>
>> Re Dan's, I was uncomfortable with the classpath loader acquiring 'memory' -
>> once it found something, it stuck it there for good until a restart, which I
>> didn't think supported the usual expectations of a classpath-ish loader -
>> although I saw that he had a valid need.
>
> As you noticed, the "memory" is used to keep the resource lookups
> quick. FileResourceLoader currently uses this same technique.
Yes, but for the classpath, not sure you want that.
>
>> So here is what I cooked up - adapters for any resource loader.
>>
>> The idea is that you make one of these, which extends ResourceLoader, and as
>> part of it's configuration, you supply the class and properties for a 'real'
>> loader, like File- or Classpath-.
>>
>> So then you make an adapter for whatever purpose you want - I tried to make
>> one copying from Dan's proposed modifications so he can test it to see if it
>> works.
>>
>> I'm not sure this is the best approach in terms of structure. Certainly if
>> this approach seems useful, we should refactor the resource system to make
>> this a formal thing - that the concept of a 'ResourceAdapter' is a first
>> class citizen, rather than this sneaky approach.
>
> 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.
What I really was getting at was to do something completely different that
this - but wanted to test the waters to see if this would work for you.
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
My inner cowboy needs to yodel.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Two Birds : WAS
"Re: [PROPOSAL] Multipath ClasspathResourceLoader"AND "i18n"
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/13/02 2:07 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> "Geir Magnusson Jr." <ge...@optonline.net> 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Two Birds : WAS "Re: [PROPOSAL] Multipath ClasspathResourceLoader"AND "i18n"
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Geir Magnusson Jr." <ge...@optonline.net> 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.
> 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).
> This just doesn't make sense to me.
Which is why I'm willing to try out your proposal...
> 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?
Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Two Birds : WAS
"Re: [PROPOSAL] Multipath ClasspathResourceLoader"AND "i18n"
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/12/02 10:13 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> "Geir Magnusson Jr." <ge...@optonline.net> writes:
>
>> On 2/11/02 9:37 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
>>
>>> "Geir Magnusson Jr." <ge...@optonline.net> 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. geirm@optonline.net
System and Software Consulting
"He who throws mud only loses ground." - Fat Albert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Two Birds : WAS "Re: [PROPOSAL] Multipath ClasspathResourceLoader"AND "i18n"
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Geir Magnusson Jr." <ge...@optonline.net> writes:
> On 2/11/02 9:37 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
>
>> "Geir Magnusson Jr." <ge...@optonline.net> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Two Birds : WAS
"Re: [PROPOSAL] Multipath ClasspathResourceLoader"AND "i18n"
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/11/02 9:37 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> "Geir Magnusson Jr." <ge...@optonline.net> writes:
>
>> On 2/11/02 8:37 PM, "Daniel Rall" <dl...@finemaltcoding.com> 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. geirm@optonline.net
System and Software Consulting
The question is : What is a Mahnamahna?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Two Birds : WAS "Re: [PROPOSAL] Multipath ClasspathResourceLoader"AND "i18n"
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Geir Magnusson Jr." <ge...@optonline.net> writes:
> On 2/11/02 8:37 PM, "Daniel Rall" <dl...@finemaltcoding.com> 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.
> 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? ;-)
Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>