I will start by saying I think we are in agreement. I am sorry that I
haven't been around.
more inline.
Jason van Zyl wrote:
>
> "Geir Magnusson Jr." wrote:
> >
> > Yes. I like the setProperty(). Agreed!
> >
> > Now, how do I store the two properties
> >
> > resource.loader = file
> > resource.loader = classpath
> >
> > in a Hashtable, Hashmap or Properties?
>
> You can store them however you like, if your app has it's own
> configuration then that's up to you. As long as you use the setProperty()
> method. Your configuration file could look like anything. It's up
> to the app to do the processing. What is in Turbine I think is
> fairly typical, you have your application configuration and
> it does the processing of its config and uses the runtime to
> set the properties accordingly.
The point was "how do I store two values for identical keys w/o painful
machinations?"
> I see what you're driving, the applications configuration is
> the applications problem. It is possible to store the properties
> in whatever format you want. I see what you are looking for
> though.
:)
> If adding the number suffix doesn't cause any problem i.e. I don't think
>
> resource.loader.1 = file
> resource.loader.2 = classpath
>
> or
>
> resource.loader = file
> resource.loader = classpath
>
> Will make any difference when using
>
> Configuration.subset("resource.loader")
>
> But I don't ever want to get into the situation where you have to tack
> on little bits of free text like ".1" to say dynamically add a resource
> loader (one day when we might) or add a template path.
Right - and that is taken care of by suggestion to change
setResourceProperty() to
addProperty( key, val )
which indicates that you are adding a value to a multivalued key. So we
can use this for any multi-valued key that comes our way in the future,
not just resource properties.
And I think that the programmer should have the freedom to do either :
addProperty( <property>, "foo");
or
setProperty( <property>.1, "foo");
So if you know something about your properties, like you do in Turbine,
then the first method will satisfy you 100%.
For me, in general I slurp in a properties file into a Properties or
something, and punch them in, and the second takes care of that.
I think we have complete coverage in three Runtime methods and can make
convenience methods in o.a.v.a.Velocity.
> So I think if you really wanted to load a properties file, alter it,
> then Velocity.init(Properties) then I think the Configuration class
> will deal with it fine internally.
As long as we define a complete configuration API for Runtime, we could
take care of this in the Velocity class. We would implement
Velocity.init(Properties) to use the setProperty()/addProperty()/init()
Runtime API, which I think covers everything.
So the fact that the Configuration class is internal is irrelevant. As
long as we define the contract of the behaviors of
setProperty()/addProperty()/init(), then internal properties management
is up to us as developers, and app developers / users aren't affected.
> So you can use a Properties class if you want,
> and
> I don't have to add any free text bits like ".1" to the end of a property.
> I think both ways will work which is fine with me.
Yep - the *only* purpose of the 'free text bit' is to make them distinct
so conventional config management techniques like the Properties can be
used by users. It also has definite meaning - it means that it is a
value for a property that can be multi-valued. That said, setProperty()
has to handle it, but I think it makes it easier in implementation -
just look for the trailing integer, snip it off, and call addProperty().
addProperty() would not require it, because you know it's a mult-valued
property just due to the fact that the user is calling addProperty().
> And your Velocity.init(Properties) could take of processing the properties
> any way you see fit. What we provide for configuration is
>
> setProperty()
> addProperty()
> init()
Yep! So do you like them?
> And the app can use those anyway it sees fit. So if you want to use a Properties
> file then you have to do the processing to make it work, though like I said I think
>
> the Configuration class will deal with it so I think we're in the clear. You're
> satsified if you can use the number suffixes to make things unique to
> classes like Properties, and I'm happy because I don't have to use free text
> bits to set properties like the template path dynamically.
Just to be clear, in addProperty() the trailing .N isn't used.
setProperty() will have to accept them, though, right?
I think we agree. This sounds great!
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
