velocity-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Will Glass-Husain" <wglasshus...@gmail.com>
Subject Re: Expanding Environmental variables patch
Date Wed, 07 May 2008 15:32:26 GMT
Hi,

Thanks for your enthusiasm and interest.  We're all Velocity developers
here...

I've never played myself with custom implementations of Extended Properties,
but that seems like a reasonable approach.

Will this patch also support system properties?  (or are they already
supported).  That seems the most useful.

Really, I'd like to see this become part of ExtendedProperties.  Makes more
sense to have that kind of substitution occur at the level.  One idea would
be to submit your patch to that project, then use the modified version with
Velocity. If you do this, let us know how it is working out.  You might even
want to post sample code on our Wiki.

If you still feel that belongs part of Velocity core, then do continue to
speak up and advocate for it being included in the Velocity code directly.

Best, WILL



On Wed, May 7, 2008 at 8:10 AM, Sanders, Charles <csanders@hoovers.com>
wrote:

> > The documentation for RuntimeInstance.setConfiguration does not state
> > that the parameter is modified, so it's rude to modify it.
>
> Ah that makes sense.
>
> >Actually, if Velocity supports this, then you can use your own
> >implementation of ExtendedProperties regardless of the response from the
> >commons collections folks.
>
> I think this is the most flexibile solution, any Velocity developers care
> to comment ?
>
>
>
> Thanks,
> Charlei
>
>
>
>
>
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: Wed 5/7/2008 8:21 AM
> To: Velocity Developers List
> Subject: Re: Expanding Environmental variables patch
>
> Charles,
>
> Sanders, Charles wrote:
> >> I actually dislike  modifying passed-in parameters
> >
> > Why?
>
> The documentation for RuntimeInstance.setConfiguration does not state
> that the parameter is modified, so it's rude to modify it. Don't forget
> that the documentation is part of the API, too, and it's supposed to be
> a stable API. If you need to modify the ExtendedProperties, create a new
> one instead and modify that one.
>
> >> I'm a little curious why this capability needs to be added to Velocity
> >> in the first place. Does anybody really use environment variables
> >> anymore, anyway?
> >
> > Err, you don't use JAVA_HOME?  I'm guessing you're not a *nix user ?
>
> I've never deployed anything on Microsoft Windows. Nobody uses
> environment variables anymore, even on *NIX. It's system properties, baby.
>
> System.getProperty("java.home")
>
> > The reason I want them in Velocity, is file.resource.loader.path only
> > accepts a full path. With several developers working on a project its a
> > pain to have explain how to update this for everyone who wants to run
> > the project.
>
> I understand the utility of properties files that know how to resolve
> references. I'm just not sure I understand why Velocity needs to do this
> and not the Properties implementation.
>
> By the way, another way to achieve your goal is to use a build script
> that replaces variables for you. Check out Apache ant, which comes with
> a whole host of utilities geared toward this purpose.
>
> > I agree the ExtendedProperties class is what needs patching, I don't
> > know how receptive they will be though.
>
> I'm sure they will be receptive. Instead of a patch, why not submit an
> entirely new class called EnvironmentExpandingExtendedProperties which
> extends ExtendedProperties. The methods you would have to override would
> be addProperty, combine, convertProperties, setProperty, and possibly
> the "load" methods.
>
> Even better, if you read the source code for ExtendedProperties you may
> find that every method used "interpolate" in order to replace
> parameterized keys and values. In that case, simply override
> interpolate() and your job is done.
>
> If you configure Velocity programatically, then you are done.
>
> If you use configuration files, you'll need to ask the Velocity folks to
> either replace their use of ExtendedProperties in their config file
> loader with EnvironmentExpandingExtendedProperties (which I doubt they'd
> do) or allow you to specify the ExtendedProperties subclass to use when
> loading configuration (which makes more sense anyway, and is more likely
> to actually be done).
>
> Actually, if Velocity supports this, then you can use your own
> implementation of ExtendedProperties regardless of the response from the
> commons collections folks.
>
> -chris
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>



-- 
Forio Business Simulations

Will Glass-Husain
wglass@forio.com
www.forio.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message