You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by "Charles N. Harvey III" <ch...@alloy.com> on 2004/02/27 16:44:49 UTC
url resource loader
Hello.
About a year ago I tested out a UrlResourceLoader and I believe it
went well. I never did wind up using it though, and I have forgotten
what happened to it. Is it still around? Is in in the core? CVS?
Thanks a lot.
Charlie
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: url resource loader
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Mar 3, 2004, at 3:10 PM, Nathan Bubna wrote:
> Geir Magnusson Jr said:
>> On Mar 3, 2004, at 1:51 PM, Nathan Bubna wrote:
>>> Charles N. Harvey III said:
>>> ...
>>>> The only question I have is, why aren't both of these resource
>>>> loaders
>>>> in the core? I understand that the URLResourceLoader is only being
>>>> used by me, but it was developed by Geir over a year go and it has
>>>> been in whiteboard unchanged for the entire time.
> ...
>>> maybe we should look at putting the URLResourceLoader in
>>> VelocityTools.
>>
>> If people like it, it's general purpose enough to go into core, as
>> there's nothing servlet-ish about URLs...
> ...
>
> true. either place would be fine with me.
>
> (though, looking at the code, it should probably do something better
> with the
> exceptions it catches in getResourceStream() before going into either
> the core
> or veltools.)
It was a quickie POC... it'll be cleaned up first...
>
> Nathan Bubna
> nathan@esha.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: url resource loader
Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr said:
> On Mar 3, 2004, at 1:51 PM, Nathan Bubna wrote:
> > Charles N. Harvey III said:
> > ...
> >> The only question I have is, why aren't both of these resource loaders
> >> in the core? I understand that the URLResourceLoader is only being
> >> used by me, but it was developed by Geir over a year go and it has
> >> been in whiteboard unchanged for the entire time.
...
> > maybe we should look at putting the URLResourceLoader in
> > VelocityTools.
>
> If people like it, it's general purpose enough to go into core, as
> there's nothing servlet-ish about URLs...
...
true. either place would be fine with me.
(though, looking at the code, it should probably do something better with the
exceptions it catches in getResourceStream() before going into either the core
or veltools.)
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: url resource loader
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Mar 3, 2004, at 1:51 PM, Nathan Bubna wrote:
> Charles N. Harvey III said:
>
> ...
>> The only question I have is, why aren't both of these resource loaders
>> in the core? I understand that the URLResourceLoader is only being
>> used by me, but it was developed by Geir over a year go and it has
>> been in whiteboard unchanged for the entire time. Also, why is the
>> WebappLoader part of Velocity Tools? Wouldn't other velocity
>> projects want to use the WebappLoader without having the
>> velocity-tools jar? Just curious. It all works for me so I am not
>> really all that concerned.
> ...
>
> The current plan for Velocity and VelocityTools is to move and/or keep
> all
> web/servlet related code in VelocityTools. This is why the
> VelocityServlet is
> now deprecated and also why the WebappLoader won't be moved into the
> core.
>
> That said, maybe we should look at putting the URLResourceLoader in
> VelocityTools.
If people like it, it's general purpose enough to go into core, as
there's nothing servlet-ish about URLs...
I'm trying to summon the wherewithal to enter the whitespace thread :)
geir
>
> Nathan Bubna
> nathan@esha.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: url resource loader
Posted by Nathan Bubna <na...@esha.com>.
Mike Curwen said:
...
> 1) Is there a concern with using VVS and another class that I created,
> which is merely a very thin wrapper around VelocityEngine? I'm mainly
> thinking about that whole singleton/separate instance thing. VVS
> currently is singleton, and I think there was a discussion here where
> someone said plans were to switch it to separate instance. Is this
> still true, or did I dream the whole thing? (I can't find that thread).
yep. i plan to switch the VVS off of singleton use as soon as i find the
time(might be a month or two before that happens), unless someone beats me to
it.
> 1A) related question: It's possible to have both the singleton *and* a
> separate instance, isn't it? They won't 'share' or collide in any way?
yep.
> 2) is inlined below..... (ok, it's right at the bottom)
>
> Nathan Bubna said:
> > Charles N. Harvey III said:
> > > Nathan Bubna wrote:
> > > >Charles N. Harvey III said:
> > > >
> > > >>Well, if anyone was wondering, it works. And it works great.
> > > >>Thanks so much for the help. There were some things that were
> > > >>confusing. Mostly, the VVS uses the WebAppLoader by
> > default, without
> > > >>telling you. So you have to explicitly setup the WebAppLoader and
> > > >>then setup the URLResourceLoader.
> > > >>
> > > >really? i can't quite remember off the top of my head,
> > but i can't
> > > >see why you would *have* to setup the WebappLoader unless
> > you wanted
> > > >it.
> > > >
> > > That's the thing, I want both.
> >
> > ah, then you do need to explicitly setup both.
> >
> > > I want WebappLoader to be the first one
> > > checked and then URLResourceLoader to be checked second.
> > > But when I setup the URLResourceLoader in velocity.properties,
> > > WebappLoader stopped working.
> > >
> > > It was because it is not explicitly defined, that when you define
> > > another loader, the new one you defined is now the only loader. To
> > > have both load up I had to define both in
> > velocity.properties. That's
> > > all.
> >
> > yep, your "resource.loader=whatever" property would override
> > the one the VVS sets by default ("resource.loader=webapp").
> >
> > since there's not really any way to remove a configured
> > resource loader, we have the VVS set the resource loader
> > props *before* loading the user's custom props (which
> > override defaults) to allow the user the option of not using
> > the WebappLoader.
> >
> > > Like, maybe the example should have WebappLoader in
> > > velocity.properties.
> >
> > hmm. yeah, that might help avoid some confusion.
> >
> > > Or, even if I define another loader, it looks at WebappLoader first
> > > anyway.
> >
> > this is definitely not gonna happen. :)
> >
>
> 2) You mean only that if someone defines a single other loader in
> velocity.properties, that it will replace the one set in VVS? But in
> the case of defining two loaders, first Webapp, second URL, then the
> desired behaviour will occur.
yep. that's what i mean.
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
RE: url resource loader
Posted by Mike Curwen <gb...@gb-im.com>.
Hey everyone,
This is an old thread, but I've been thinking about it recently. I have
an app that uses Velocity both as a back-end template merging 'service'
(ie: the results do not get sent to a servlet response), and it's also a
'traditional' velocity based webapp that displays, in a browser, the
results of velocity template merging.
So I have two questions:
1) Is there a concern with using VVS and another class that I created,
which is merely a very thin wrapper around VelocityEngine? I'm mainly
thinking about that whole singleton/separate instance thing. VVS
currently is singleton, and I think there was a discussion here where
someone said plans were to switch it to separate instance. Is this
still true, or did I dream the whole thing? (I can't find that thread).
1A) related question: It's possible to have both the singleton *and* a
separate instance, isn't it? They won't 'share' or collide in any way?
2) is inlined below..... (ok, it's right at the bottom)
> -----Original Message-----
> From: Nathan Bubna [mailto:nathan@esha.com]
> Sent: Wednesday, March 03, 2004 2:00 PM
> To: Velocity Users List; charlieh@alloy.com
> Subject: Re: url resource loader
>
>
> Charles N. Harvey III said:
> > Nathan Bubna wrote:
> > >Charles N. Harvey III said:
> > >
> > >>Well, if anyone was wondering, it works. And it works great.
> > >>Thanks so much for the help. There were some things that were
> > >>confusing. Mostly, the VVS uses the WebAppLoader by
> default, without
> > >>telling you. So you have to explicitly setup the WebAppLoader and
> > >>then setup the URLResourceLoader.
> > >>
> > >really? i can't quite remember off the top of my head,
> but i can't
> > >see why you would *have* to setup the WebappLoader unless
> you wanted
> > >it.
> > >
> > That's the thing, I want both.
>
> ah, then you do need to explicitly setup both.
>
> > I want WebappLoader to be the first one
> > checked and then URLResourceLoader to be checked second.
> > But when I setup the URLResourceLoader in velocity.properties,
> > WebappLoader stopped working.
> >
> > It was because it is not explicitly defined, that when you define
> > another loader, the new one you defined is now the only loader. To
> > have both load up I had to define both in
> velocity.properties. That's
> > all.
>
> yep, your "resource.loader=whatever" property would override
> the one the VVS sets by default ("resource.loader=webapp").
>
> since there's not really any way to remove a configured
> resource loader, we have the VVS set the resource loader
> props *before* loading the user's custom props (which
> override defaults) to allow the user the option of not using
> the WebappLoader.
>
> > Like, maybe the example should have WebappLoader in
> > velocity.properties.
>
> hmm. yeah, that might help avoid some confusion.
>
> > Or, even if I define another loader, it looks at WebappLoader first
> > anyway.
>
> this is definitely not gonna happen. :)
>
2) You mean only that if someone defines a single other loader in
velocity.properties, that it will replace the one set in VVS? But in
the case of defining two loaders, first Webapp, second URL, then the
desired behaviour will occur.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: url resource loader
Posted by Nathan Bubna <na...@esha.com>.
Charles N. Harvey III said:
> Nathan Bubna wrote:
> >Charles N. Harvey III said:
> >
> >>Well, if anyone was wondering, it works. And it works great. Thanks
> >>so much for the help. There were some things that were confusing.
> >>Mostly, the VVS uses the WebAppLoader by default, without telling you.
> >>So you have to explicitly setup the WebAppLoader and then setup the
> >>URLResourceLoader.
> >>
> >really? i can't quite remember off the top of my head, but i can't see why
> >you would *have* to setup the WebappLoader unless you wanted it.
> >
> That's the thing, I want both.
ah, then you do need to explicitly setup both.
> I want WebappLoader to be the first one
> checked and then URLResourceLoader to be checked second.
> But when I setup the URLResourceLoader in velocity.properties,
> WebappLoader stopped working.
>
> It was because it is not explicitly defined, that when you define another
> loader, the new one you defined is now the only loader. To have both load
> up I had to define both in velocity.properties. That's all.
yep, your "resource.loader=whatever" property would override the one the VVS
sets by default ("resource.loader=webapp").
since there's not really any way to remove a configured resource loader, we
have the VVS set the resource loader props *before* loading the user's custom
props (which override defaults) to allow the user the option of not using the
WebappLoader.
> Like, maybe the example should have WebappLoader in velocity.properties.
hmm. yeah, that might help avoid some confusion.
> Or, even if I define another loader, it looks at WebappLoader first anyway.
this is definitely not gonna happen. :)
> This probably isn't much of a concern for many people, so I wouldn't
> worry about it much.
...
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Trouble with designers
Posted by "J. B. Rainsberger" <jb...@rogers.com>.
Shawn Church wrote:
> Quoting "J. B. Rainsberger" <jb...@rogers.com>:
>
>
>>Look at Tapestry, if you haven't already. It uses <span> tags and IDs
>>to
>>identify dynamic content. I think you'll have to do the same. For
>>each
>>block of VTL, craft a corresponding <span> tag with corresponding ID.
>
> I have looked at Tapestry a little but was wondering if anyone had
> actually used it. It seems to be in early development, so I was unsure
> about its maturity/stability.
I haven't used it yet, but I will get to it. I'll particularly be
interested to see how testable the design is.
>>Build an XSL stylesheet to replace the <span> tag with your VTL
>>fragments. It's not nice, but it would work.
>>
>>1. Web designer changes layout.
>>2. Run XSLT on web designer's page to generate Velocity template.
>>3. Use Velocity template in production.
>
> I can see how this would work as a replacement for $variables, but how
> would it work for #if directives
It works for /anything/. It's like custom tags in JSP: you can replace
the tag with arbitrary VTL code.
It doesn't help Dreamweaver, though, since only the variables syntax is
the same between JSP 2.0 and VTL.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Let's write software that people understand
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
OT: Re: Trouble with designers
Posted by Mike Kienenberger <mk...@alaska.net>.
Shawn Church <sh...@boxity.com> wrote:
> I have looked at Tapestry a little but was wondering if anyone had
> actually used it. It seems to be in early development, so I was unsure
> about its maturity/stability.
I really wish I'd been able to port my WebObjects project to Tapestry
instead of Struts, but for political reasons it wasn't possible. From what
I've heard, it's far better than struts (not that THAT would be much of a
challenge) and comparable to WebObjects. Of course, that says nothing of
the maturity/stability.
-Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Trouble with designers
Posted by Shawn Church <sh...@boxity.com>.
Quoting "J. B. Rainsberger" <jb...@rogers.com>:
> Look at Tapestry, if you haven't already. It uses <span> tags and IDs
> to
> identify dynamic content. I think you'll have to do the same. For
> each
> block of VTL, craft a corresponding <span> tag with corresponding ID.
I have looked at Tapestry a little but was wondering if anyone had
actually used it. It seems to be in early development, so I was unsure
about its maturity/stability.
> Build an XSL stylesheet to replace the <span> tag with your VTL
> fragments. It's not nice, but it would work.
>
> 1. Web designer changes layout.
> 2. Run XSLT on web designer's page to generate Velocity template.
> 3. Use Velocity template in production.
I can see how this would work as a replacement for $variables, but how
would it work for #if directives, for example:
#if($dog)
<tr><td>I have a dog.</td></tr>
#elseif($cat)
#parse("catTemplate.vm")
#else
<form...>
...
</form>
#end
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Trouble with designers
Posted by "J. B. Rainsberger" <jb...@rogers.com>.
Serge Knystautas wrote:
> Shawn Church wrote:
>
>> Has anyone had any experience with Tapestry or other Java-based
>> products which work more seamlessly with Dreamweaver? My designers
>> are not absoultely tied to Dreamweaver, but it seems to be the most
>> configurable.
>
>
> Enhydra created this templating notion called XMLC, that would work well
> (in theory) with HTML designers and their toolz. Take regular HTML,
> including dummy data as your template, format willy-nilly, mark
> appropriate elements with specific names/ids. The XMLC logic looks for
> elements by "id" and loops them, conditionally displays them, populates
> dynamic values, etc...
>
> http://www.enhydra.org/
>
> I don't think there's a lot of traction with it anymore as the original
> commercial company(s) behind it went under (and in the end it didn't
> make things easier). This isn't a rousing endorsement, but I know
> people who still use it, and it could work well with a WYSIWYG editing
> environment.
I was about to suggest something similar. The bottom line is that
Dreamweaver wants HTML/XML tags, and not #thisStuff(). The only way
around the problem is to give it what it wants.
Look at Tapestry, if you haven't already. It uses <span> tags and IDs to
identify dynamic content. I think you'll have to do the same. For each
block of VTL, craft a corresponding <span> tag with corresponding ID.
Build an XSL stylesheet to replace the <span> tag with your VTL
fragments. It's not nice, but it would work.
1. Web designer changes layout.
2. Run XSLT on web designer's page to generate Velocity template.
3. Use Velocity template in production.
This will do until you move your presentation technology to Tapestry,
WebObjects, XSLT or somesuch. It appears that Velocity will not work in
your environment for the time being.
Good news, though: DW will /have/ to support the JSP 2.0 expression
language soon, otherwise they'll lose their marketshare of web designers
working in JSP-type shops. When that happens, DW will /probably/ support
Velocity quite well, since the corresponding syntaxes (syntaces?) are so
similar.
Good luck.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Let's write software that people understand
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Trouble with designers
Posted by Serge Knystautas <se...@lokitech.com>.
Shawn Church wrote:
> Has anyone had any experience with Tapestry or other Java-based
> products which work more seamlessly with Dreamweaver? My designers are
> not absoultely tied to Dreamweaver, but it seems to be the most
> configurable.
Enhydra created this templating notion called XMLC, that would work well
(in theory) with HTML designers and their toolz. Take regular HTML,
including dummy data as your template, format willy-nilly, mark
appropriate elements with specific names/ids. The XMLC logic looks for
elements by "id" and loops them, conditionally displays them, populates
dynamic values, etc...
http://www.enhydra.org/
I don't think there's a lot of traction with it anymore as the original
commercial company(s) behind it went under (and in the end it didn't
make things easier). This isn't a rousing endorsement, but I know
people who still use it, and it could work well with a WYSIWYG editing
environment.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Trouble with designers
Posted by Mike Kienenberger <mk...@alaska.net>.
Shawn Church <sh...@boxity.com> wrote:
> Has anyone had any experience with Tapestry or other Java-based
> products which work more seamlessly with Dreamweaver? My designers are
> not absoultely tied to Dreamweaver, but it seems to be the most
> configurable.
I know there used to be a webobjects dreamweaver plug-in.
However, webobjects template tags always are of the form <webobjects
name=something>stuff</webobjects>
-Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Trouble with designers
Posted by Shawn Church <sh...@boxity.com>.
I am hitting a wall more and more often regarding the use of WYSIWYG
html editors such as Dreamweaver with Velocity templates. In the past
I have for the most part worked independently (at least on non-static
content), but I am now in an environment with a couple of full-time
designers who are accustomed to using Dreamweaver for nearly all page
layout.
Anyone who has attempted to customize Dreamweaver to work nicely with
Velocity templates has probably discovered that it really doesn't work
well unless the templates are very simple. I can configure DW to
recognize VTL, but the nature of a dynamically-generated page where
content is selectively parsed/rendered based on context data doesn't
fit the static orientation of DW. For this to work well, DW would need
to implement a Velocity parser and would also need to provide an
ability to populate a context for the parser's use in the merge.
Does anyone have any suggestions of how to deal with this? Obviously
hand-editing the templates have always been my preference and solution,
but for the designers this is really not acceptable. If this is the
only option, then the use of Velocity will be severly limited to only
intranet applications at best. Velocity is my tool of choice, but
there are already talks of boycotting it in favor of ColdFusion, .NET,
etc., none of which I am very fond.
Has anyone had any experience with Tapestry or other Java-based
products which work more seamlessly with Dreamweaver? My designers are
not absoultely tied to Dreamweaver, but it seems to be the most
configurable.
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: url resource loader
Posted by "Charles N. Harvey III" <ch...@alloy.com>.
Nathan Bubna wrote:
>Charles N. Harvey III said:
>
>
>>Well, if anyone was wondering, it works. And it works great. Thanks
>>so much for the help. There were some things that were confusing.
>>Mostly, the VVS uses the WebAppLoader by default, without telling you.
>>So you have to explicitly setup the WebAppLoader and then setup the
>>URLResourceLoader.
>>
>>
>
>really? i can't quite remember off the top of my head, but i can't see why
>you would *have* to setup the WebappLoader unless you wanted it.
>
>
That's the thing, I want both. I want WebappLoader to be the first one
checked and then URLResourceLoader to be checked second. But when I setup
the URLResourceLoader in velocity.properties, WebappLoader stopped working.
It was because it is not explicitly defined, that when you define another
loader, the new one you defined is now the only loader. To have both load
up I had to define both in velocity.properties. That's all. Like, maybe
the example should have WebappLoader in velocity.properties. Or, even if
I define another loader, it looks at WebappLoader first anyway. This
probably
isn't much of a concern for many people, so I wouldn't worry about it much.
>...
>
>
>>The only question I have is, why aren't both of these resource loaders
>>in the core? I understand that the URLResourceLoader is only being
>>used by me, but it was developed by Geir over a year go and it has
>>been in whiteboard unchanged for the entire time. Also, why is the
>>WebappLoader part of Velocity Tools? Wouldn't other velocity
>>projects want to use the WebappLoader without having the
>>velocity-tools jar? Just curious. It all works for me so I am not
>>really all that concerned.
>>
>>
>...
>
>The current plan for Velocity and VelocityTools is to move and/or keep all
>web/servlet related code in VelocityTools. This is why the VelocityServlet is
>now deprecated and also why the WebappLoader won't be moved into the core.
>
>That said, maybe we should look at putting the URLResourceLoader in
>VelocityTools.
>
>
I see. Now I remember that discussion from a few months back. Well, I'm a
big fan of URLResourceLoader, so I would vote for it to be in VelocityTools.
>Nathan Bubna
>nathan@esha.com
>
>
>
Charlie
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: url resource loader
Posted by Nathan Bubna <na...@esha.com>.
Charles N. Harvey III said:
> Well, if anyone was wondering, it works. And it works great. Thanks
> so much for the help. There were some things that were confusing.
> Mostly, the VVS uses the WebAppLoader by default, without telling you.
> So you have to explicitly setup the WebAppLoader and then setup the
> URLResourceLoader.
really? i can't quite remember off the top of my head, but i can't see why
you would *have* to setup the WebappLoader unless you wanted it.
...
> The only question I have is, why aren't both of these resource loaders
> in the core? I understand that the URLResourceLoader is only being
> used by me, but it was developed by Geir over a year go and it has
> been in whiteboard unchanged for the entire time. Also, why is the
> WebappLoader part of Velocity Tools? Wouldn't other velocity
> projects want to use the WebappLoader without having the
> velocity-tools jar? Just curious. It all works for me so I am not
> really all that concerned.
...
The current plan for Velocity and VelocityTools is to move and/or keep all
web/servlet related code in VelocityTools. This is why the VelocityServlet is
now deprecated and also why the WebappLoader won't be moved into the core.
That said, maybe we should look at putting the URLResourceLoader in
VelocityTools.
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: url resource loader
Posted by "Charles N. Harvey III" <ch...@alloy.com>.
Well, if anyone was wondering, it works. And it works great. Thanks
so much for the help. There were some things that were confusing.
Mostly, the VVS uses the WebAppLoader by default, without telling you.
So you have to explicitly setup the WebAppLoader and then setup the
URLResourceLoader.
Here is the example if anyone is wondering:
#----------------------------------------------------------------------------
# RESOURCE MANAGEMENT
#----------------------------------------------------------------------------
# Allows alternative ResourceManager and ResourceCache implementations
# to be plugged in.
#----------------------------------------------------------------------------
resource.manager.class =
org.apache.velocity.runtime.resource.ResourceManagerImpl
resource.manager.cache.class =
org.apache.velocity.runtime.resource.ResourceCacheImpl
resource.loader = webapp, url
webapp.resource.loader.description = Velocity Webapp Resource Loader
webapp.resource.loader.class =
org.apache.velocity.tools.view.servlet.WebappLoader
webapp.resource.loader.path = /
webapp.resource.loader.cache = false
webapp.resource.loader.modificationCheckInterval = 0
url.resource.loader.description = Velocity URL Resource Loader
url.resource.loader.class =
org.apache.velocity.runtime.resource.loader.URLResourceLoader
url.resource.loader.root = http://static.carepackages.com/
url.resource.loader.cache = false
url.resource.loader.modificationCheckInterval = 0
#----------------------------------------------------------------------------
The only question I have is, why aren't both of these resource loaders
in the
core? I understand that the URLResourceLoader is only being used by me, but
it was developed by Geir over a year go and it has been in whiteboard
unchanged
for the entire time. Also, why is the WebappLoader part of Velocity
Tools? Wouldn't
other velocity projects want to use the WebappLoader without having the
velocity-tools
jar? Just curious. It all works for me so I am not really all that
concerned.
Thanks again for all the help.
Charlie
Geir Magnusson Jr wrote:
>
> On Feb 27, 2004, at 10:44 AM, Charles N. Harvey III wrote:
>
>> Hello.
>> About a year ago I tested out a UrlResourceLoader and I believe it
>> went well. I never did wind up using it though, and I have forgotten
>> what happened to it. Is it still around? Is in in the core? CVS?
>
>
> It's in whiteboard/geir
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: url resource loader
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Feb 27, 2004, at 10:44 AM, Charles N. Harvey III wrote:
> Hello.
> About a year ago I tested out a UrlResourceLoader and I believe it
> went well. I never did wind up using it though, and I have forgotten
> what happened to it. Is it still around? Is in in the core? CVS?
It's in whiteboard/geir
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org