Jason van Zyl wrote:
>
> "Geir Magnusson Jr." wrote:
>
> > Jason van Zyl wrote:
> >
> > > 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.
> >
> > I'll see your posit and raise you one :
> >
> > 3) <guess>
> >
> > As promised, I asked my client yesterday, first thing when I walked in
> > (or at least their director of software development :
> >
> > "How do you manage configuration information inside your application?"
> >
> > After looking at in a way I interpreted to be wondering why they pay me
> > money to tell them things, he said
> >
> > "Properties class"
>
> That is fully covered in 2)
See the very next line - I conceded that we can work this out :)
> >
> >
> > I will surprise you all as noting this is irrelevant to the discussion :
> > ) But for anyone still reading these, I wanted to report back...
> >
[SNIP]
> > /**
> > * sets the value of the property <prop> to the value <value>.
> > * Repeated call with the same <prop> simply replace the existing value
> > */
> > boolean setProperty( String prop, String value )
> >
> > /**
> > * adds a value to the multivalued property <prop>
> > */
> > boolean addProperty( String prop, String value )
> >
> > /**
> > * takes the user properties as set via above if any,
> > * lays them over the default prop set, and inits
> > */
> > init()
> >
> > This makes it lucidly clear what is going on - and you don't get stuck
> > with side effects of the internal configuration turning a scalar valued
> > property into a vector-valued one when you are simply trying to replace
> > a value. Further, the Runtime core is agnostic wrt format or container
> > - be it file, Properties, Configuration, Hashtable.
> >
> > The advantages :
> >
> > Turbine can do :
> >
> > Runtime.addProperty(Runtime.FILE_RESOURCE_LOADER_PATH, path1);
>
> So are you saying we can remove the number suffixes! Yaaay!!!
> Or as long as I don't have to use them with the addProperty() then
> I can live with that.
YES! YOU WIN THE PRIZE! :)
Having the 'addProperty()' [or something with a better name...], you are
indicating to the Runtime 'Here is *another* value for the property
specified.'
So Turbine, or any other app, can simply do
for(int i = 0; i < pathvec.length; i++)
{
Runtime.addProperty( Runtime.FILE_RESOURCE_LOADER_PATH, pathvec[i] );
}
(if you stored them in a vector)
or whatever.
The 'catch' is that I firmly believe that we must make the following
rule about our properties :
When a property can have multiple values, you may *either* use
setProperty( <propertyname>.N, value );
or
addProperty( <propertyname>, value );
This way, a user can put
<propertyname>.1 = val1
<propertyname>.2 = val2
in the velocity.properties file (or their application properties glob),
and then easily handle them in a Properties, a Configuration, a Hash,
etc....
This means that our setProperty() will have to be sort of smart - if
the property ends with a .<integer>, it will just call addProperty(),
and addProperty() will have th smarts to deal.
>
> >
> > Runtime.setProperty(Runtime.RUNTIM_LOG, log);
> > Runtime.init()
> >
> > and any of us from the Cult of Properties or the Configuration Tribe, or
> > any upcoming method du jour :
> >
> > for( Enumeration e = p.propertyNames(); e.hasMoreElements(); )
> > {
> > String s = (String) e.nextElement();
> > Runtime.setProperty(s, p.getProperty(s));
> > }
> > Runtime.init();
> >
> > Of course, note that it is critical that we fix our properties anyway -
> > right now, the *.resource.path properties are such that you *CANNOT* use
> > any Map-like container to hold them, so you can't mix them with your
> > application properties, and you can't use Properties.load() to load
> > them, and....
> >
> > For example, if you have a situation where your Velocity properties are
> > split between a static set, and something you figure out at runtime,
> > then you would have to manually parse the properties file and store in a
> > Vector of Hashes or something. Ug.
> >
> > > 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.
> >
> > Yep - and I think that your other good ideas on this issue re
> >
> > resource.loader = foo
> > resource.loader.foo.<prop>
> >
> > will help solve this completely. But we can do that next.
> >
> > > Any thoughts?
> >
> > I'll summarize :
> >
> > I am +1000 for simplifying Runtime. I have wanted to for months. (That
> > was the motivation behind the o.a.v.a.Velocity class)
> >
> > I believe we can achieve everything we need if Runtime supports the
> > following methods
> >
> > setProperty( key, val ) : replaces the value of key with val
> > addProperty( key, val ) : adds to a multivalued property (not in love
> > with method name...)
> > Runtime.init() : takes the default properties, replaces any values with
> > any in the 'user properties' set via setProperty() and addProperty().
> >
> > this means that you would have full control from the app layer to reset,
> > set scalar and make 'vector' properties.
> >
> > However, this is contingent upon making our properties unique - any
> > vector property must have a 'uniqueifying' integer at the end of it, and
> > setProperty() will do the right thing. That integer can be used for
> > ordering if relevant.
> >
> > I volunteer to make this work, the trailing integer bit, if someone else
> > doesn't want to.
> >
> > What this means is that we have now precisely defined a configuration
> > API : we don't care what form the application uses to hold it, we don't
> > care what format on disk they are stored - we can support all currently
> > known management mechanisms.
> >
> > Now, it is really easy to do an init( filename ), init( Properties ),
> > init( Configuration ), init( whatever), so I will add to the Velocity
> > application helper class the following :
> >
> > init( String filename ) : as it won't be in Runtime anymore
> > init( Properties props )
> > init( Configuration config )
> > ?
>
> We don't need the init(Configuration).
Why? I mean in the 'Velcoity' class - not Runtime. If the
Configuration class can be shared, and people start using it in their
projects to hold configuration, we should support accepting it in the
Velocity helper class.
I agree that we should minimize the Runtime config interface, and I
think that we are in agreement on that.
> >
> >
> > That way, application developers have the support for convenient use,
> > but we do the right thing and simplify Runtime. Good stuff, Jason.
> >
> > Apologies in advance : I am away again today fighting the good fight
> > getting Velocity integrated into another production system for a client,
> > so you won't hear a peep from me til this evening.
> >
> > I also have a few things for TODO, so you will see them then.
> >
> > Viva la Velocity!
> >
> > geir
> >
> > --
> > Geir Magnusson Jr. [EMAIL PROTECTED]
> > Developing for the web? See http://jakarta.apache.org/velocity/
>
> --
> jvz.
>
> Jason van Zyl
> [EMAIL PROTECTED]
>
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/turbine
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
