Jon Stevens wrote:
>
> another reason to get rid of Properties:
>
> If we move to an XML based configuration, we will need a way to do that
> anyway and you can't map a Properties object to all of the different forms
> of XML configuration that are possible. We could make the Configuration
> object an interface and then have PropertiesConfiguration and
> XMLConfiguration implementations.
Hm. Can see another discussion coming :)
I am not suggesting that we don't use the Configuration. It's a nice
bit of code.
What I am trying to convince y'all of is that Properties seem to be a
common way for people to deal with configuration information that isn't
deeply structured, and ours isn't.
So the summary is this : because (I think) that we can structure
(without heavy lifting) our properties such that both Properties and
Configurations will work, we should do it. I don't want to FORCE people
to use a Configuration object to work with Velocity, as they may already
have existing Properties in their apps. We aren't adding anything that
is confusing them - because they already know how to deal with
Properties.
At worst, our init(Properties) simply digs out the data and places in a
Configuration.
When our configuration is best structured in XML, then we do that,
although I would still think that we will be able to get away with
regular properties for quite a while...
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
