Hi,
While mulling over the configuration I think I came up with a solution
to the whole problem. I'll outline what I propose, and I think it covers
any type of initialization with the fewest number of methods in
the Runtime.
First, we want to simplify the Runtime. Geir and I have been discussing
this, and I think it would be possible to get rid of the following
methods:
Runtime.setProperties()
Runtime.setDefaultsProperties()
We can take care of internally of making sure that the defaults are laid
down before any customizations are made. I think this would simplify
the Runtime initialization API.
Now, I posit that there are only two ways that an application using
Velocity would want to initialize the Runtime:
1) Using an external configuration file
2) Grab configuration information from any number of different
sources. Most likely and application configuration file, but it
could be from a database, LDAP server, or what have you.
To satisfy these two possibilities, I propose the two following methods:
1) This is the case where the client app simply wants to pull
in an external configuration file. I propose the following as
the standard way of pulling in an external configuration file.
Runtime.init(String configuration)
Now this allows the use of an external configuration file and decouples
us from any particular class. We get rid of the Properties vs
Configuration
class argument because it no longer matters. And the client app doesn't
have to
bother with creating a Properties/Configuration object, Velocity
will do it internally. Easier for the client app, and no coupling to
a configuration class.
And users currently using this method will have to make no changes
to there code because a Configuration object is made from the
file referred to by 'configuration'. This very simple abstraction
makes things a lot simpler: no more concerns over using a
particular class for runtime intializations.
If we change the internal representation again to another type of
config file then again client code will not have to change. The format
of the configuration may change (say we move to XML) but the code
will not have to change.
I think this is the simplest method for initializing the runtime with
an external configuration file and allows us flexibility in the
future.
2) This is the case where the client application grabs velocity
configuration
from whatever source it chooses. I will use Turbine as an example:
Runtime.setSourceProperty(Runtime.FILE_RESOURCE_LOADER_PATH, path1);
Runtime.setProperty(Runtime.RUNTIM_LOG, log);
Runtime.init()
Now I agree with Geir that a more deterministic way to set a resource
loader property would be good, but that is peripheral to this proposal.
Back to the argument at hand. An application can grab its velocity
configuration information from any source it chooses and use the
Runtime to directly set the required properties. Again the issue of
using a
Properties class or Configuration class disappears because it
doesn't matter.
So I would propose 1) and 2) as the standard methods for initializing
the Velocity runtime:
1) Both methods are simple.
2) They require no coupling to a Properties or Configuration class
so the issue we have been arguing about disappear.
3) Both methods do not require the client application to create
any additional objects and the same amount of flexibility is
granted.
It is true that some applications use the init(Properties) method, but
I think this is a small thing to change and the overall result is that
the Runtime is simplified and we have 'standard' ways to
initialize the Runtime that provide total freedom, and a are
free from being locked into any Properties/Configuration
class for initialization.
I think this covers all the bases: provides the required flexibility
and simplies things in the Runtime, and will give us a way to
provide our users with easiest ways to initialize the Runtime
to suit their needs.
Any thoughts?
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
