avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Proposed change to Parameters:
Date Tue, 25 Sep 2001 19:31:46 GMT
Peter Donald wrote:
> On Tue, 25 Sep 2001 23:40, Berin Loritsch wrote:
> > Axis has a consept for options (equivalent to our parameters)
> > that our existing Parameters object does not satisfy.  It is
> > the concept of "locked" parameters.
> >
> > The approach is in between the two states our Parameters object
> > can handle.  Currently we have completely modifiable or read only.
> > The change would allow the markup to be changed to:
> >
> > <parameter name="foo" value="bar" locked="true"/>
> > <parameter name="baz" value="vip"/>
> >
> > The additional parameter (if present) will lock a parameter no
> > matter what state the object is in.
> >
> > That way, a run-time system can have parameters that are modified
> > at specific times--but keep certain params from changing during
> > the life of the system.
> I am fairly sure I don't like this. If parts are read-only and parts are
> read-write then IMHO they should not be part of same Parameters object. A
> possible solution to get around this would be to allow Parameters to have a
> parent and make it possible to specify who to read properties from first.
> (This would mean that properties were always accessed from parent first and
> then from child or vice versa). So you would have something like
> Parameters parent = new Parameters();
> ...setup immutable variables here...
> parent.makeReadOnly();
> Parameters child1 = new Parameters( parent, false );
> ...setup non "locked" parameters here...
> Then later on
> Parameters child2 = new Parameters( parent, false );
> child2.merge( child 1 );
> ...setup non "locked" parameters here for second time...
> Actually this is what I partially do in quite a few of my apps. But I do it
> manually and instead of using term parent I use term defaults ;)

There are three issues with your approach:

1) If the parent is accessed first, then you can never change the value of
   a parameter.  Parameters will always return the value of the parent.

2) If the child is accessed first, then you can override a "locked" value.

3) When deriving your Parameters object from a Configuration object set, you
   cannot determine which are meant to be locked, and which are allowed to be
   changed.  Instead you are forced to have the parameters specified in two
   locations.  This makes automatic incorporation in Excalibur's ComponentManager
   near impossible.

The hierarchical Parameters approach would be useful when we are adding new
sets of Parameters that are accessible to children.  It does not address management
of Parameterizable objects where a system is designed to change during its

> > and a "fromConfiguration"
> > method that allows you to specify the element name for a parameter.
> > The attributes would be the same, but a project would be able to
> > use the name "option" instead of "parameter" if it wanted to.
> Seems kinda ugly to me.

If you have a better way of implementing the same thing let me know.  The thing
is that we are forcing all configuration schemes to be the same.  The new
fromConfiguration() method allows projects to easily support different names
without breaking anything.

The default behavior has not changed in the least.

To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

View raw message