Hi Stephen, looks good :-) This makes it also useable in many other circumstances.
Do you think it makes sense to add this context-stuff to ExcaliburComponentManager? We're using Cocoon and thus have no chance to modify the context without patching cocoon :-( Adding this feature to ECM would make it easy to setup context from outside without being forced to have full control over the framework. What do you think? Wolfram > -----Original Message----- > From: Stephen McConnell [mailto:[EMAIL PROTECTED]] > Sent: Saturday, March 09, 2002 1:39 PM > To: Avalon Developers List > Subject: RE: |PATCH] Re: Proposal for globals in conf files ? > > > > Wolfram: > > Have played around a bit with the context stuff you posted. As I > cannot use ECM, but have a need for just the sort of thing your > describing, I put together a static helper class variant and posted > it to scratchpad/context. > > Changes that I have added include the ability to declare the class > of the context. > > <context class="net.osm.value.DefaultValueContext"> > ... > </context> > > The context class must implement a constructor with the following > arguments > > Map data, Context parent > > I have also tweaked the code to apply context arguments to the map > instead of a DefaultContext. Derived context values are added to > the map instead of the context and the map is supplied to the context > via the constructor. If no "class" attribute is defined, the default > action is to use the framework DefaultContext( Map data, > Context parent) > constructor. > > Let me know what you think. > > Cheers, Steve. > > > > -----Original Message----- > > From: Eisert, Wolfram (ext.) > [mailto:[EMAIL PROTECTED]] > > Sent: Friday, 08 March, 2002 14:56 > > To: '[EMAIL PROTECTED]' > > Subject: |PATCH] Re: Proposal for globals in conf files ? > > > > > > Hi all, > > > > attached is a patch to add attributes from the configuration > > file to the context of ExcaliburComponentManager. > > > > Regarding to > > http://marc.theaimsgroup.com/?l=avalon-dev&m=101439200608340&w=2 > > I have extented ECM to read a <context/>-section out of the > config-file > > and add it to the current context. > > > > The context-section should look like > > > > <context> > > <!-- Adding a String-Attribute --> > > <entry name="attribute-name" value="attribute-value"/> > > > > <!-- Adding a specified Object-type with default > constructor --> > > <entry name="attribute-name" type="classname"/> > > > > <!-- Adding a specified Object-type with String-constructor --> > > <entry name="attribute-name" value="attribute-value" > > type="classname"/> > > > > <!-- Adding a specified Object-type (with > multiple-value-constructor) > > --> > > <entry name="attribute-name" type="classname"> > > <!-- Constructur-Value String --> > > <parameter value="constructor-value"> > > <!-- Constructur-Value specified Object-type with default > > constructor --> > > <parameter type="classname"> > > <!-- Constructur-Value specified Object-type or > primitve with > > String constructor --> > > <parameter type="classname or primitve" > value="contructor-value"> > > </entry> > > </context> > > > > In the value-attributes you can refer to already existing > > context-attributes > > through ${context-attribute}. > > > > I.e. > > <contex> > > <entry name="version" value="2.0"/> > > <entry name="release-info" type="java.io.File"> > > <parameter value="/usr/local/doc/${version}/release.html"/> > > </entry> > > </context> > > > > > > What do you think? > > > > Wolfram > > > > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
