Jose Alberto Fernandez wrote:
>
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Goodness. What is my ISP doing now???
> >
> > 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.
> >
>
> Not that I like to rain on your party, but have you considered that there is
> no guarantee Properties.getKeys() and so on will give you the properties in
> the same order as they were in the file.
I don't really give a rat's patootie about the Properties class. Not
about the Properties class, this thread boils down to making a minimal
but complete Runtime API, defining a set of properties convenient for
application programmers to deal with without making our own life
miserable, and producing a set of 'helper' routines in the Velocity
class that make it easy for app programmers to init() velocity with
common property management patterns. (Like a Properties)
To address the point, which is a good one, I can use a TreeMap if I care
and want to access via name/value, or a Vector of Hashtables or
something if I don't care about access myself.
> What that means is that you may get:
>
> setProperty("config.property.5", "value5")
> setProperty("config.property.3", "value3")
> setProperty("config.property.2", "value2")
> setProperty("config.property.1", "value1")
> setProperty("config.property.4", "value4")
>
> Now, if "config.property" has a value on the default configuration, how
> do you know when to replace the old values and when to add to the existing?
Jason hasn't answered with his POV on my suggestion that
setProperty(<key>, null) will reset a property, but that would be a way.
> So I am not sure you are not back on square one in the case of Properties.
Let me try to be clear - I don't care about the java.util.Properties per
se - I care that we are defining properties that aren't distinguishable
and therefore a bit of trouble to manage.
Jason's internals can deal with this problem - ordering the <prop>.N
values for a <prop> or we require that app programmers send them in
order. Something to decide.
> > 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.
>
> As long as this class is intelligent enough as to deal with the above
> issue, then everything is fine.
That's the hope here - we make the core methods in Runtime 'complete',
we make the convenience methods in Velocity correct, and then we don't
make every user have to rewrite and solve the same thing for each use.
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
