Jose Alberto Fernandez wrote:
> 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.
>
> 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")
>
Just to be clear - I am not married to the .N stuff. All I am hoping
for is a way that makes it easy to manage and understand our properties,
for the average user.
It and the
prop = <foo>,<bar>,<woogie>
approach are the only two ways I can think of in which the properties
set from Velocity could be handled easily and nicely by both app
programmers and the Velocity core stuff.
I figured that <prop>.N is easy to parse - so detecting as a
multi-valued property is easy.
But in some ways <foo>,<bar>,<woogie> is even easier : if we like that,
and can be sure that we can work out a good delimiter, and
setProperty() would take that and do the right thing, that would work
too? The Configuration class can already deal with that anyway, so it
seems like a layup.
And the addProperty() configuration model is untouched - there the app
would pass the values individually.
So all could be happy there too.
Peace, harmony, hugs and kisses.
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
