The relation exists only in the contribution elements. E.g. <provider prefix="service" service-id="ServiceObjectProvider"/>
The SchemaProcessor knows which Element it is currently processing and will thus when addElement() is called both add the object on the stack to the List of contributions as well as add it to the Map by retrieving the value of the key attribute of the Element being processed. Is there too much magic going on here? --knut On Tue, 23 Nov 2004 13:55:48 -0500, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > I like this a lot ... but I don't see how the key (from the prefix > attribute) is related to the service object added to the configuration > via the <invoke-parent>. I can't see how the prefix key can have > anything other than a org.apache.hivemind.Element as its value. > > On Tue, 23 Nov 2004 16:55:17 +0100, Knut Wannheden > > > <[EMAIL PROTECTED]> wrote: > > Hi all, > > > > I have been working on the support for accessing / injecting > > configurations as Maps. I've implemented it using an additional > > "key-attribute" attribute on <element>. As a result the objects > > created (and pushed onto the stack) by the <rules> or <conversion> > > element will also be made available as keyed entries in a Map. > > > > I was just looking for some good candidates in HiveMind codebase which > > could benefit from mapped configurations and realized that this is > > even cooler than I first thought :-) > > > > Take the hivemind.ObjectProviders for example. Here we could now > > inject the configuration as a Map of ObjectProviderContribution > > objects keyed on the prefix String. This in itself wouldn't be very > > helpful as the ObjectTranslator service (into which the configuration > > is injected) still needs to process every entry in the Map. But when > > one realizes that the ObjectProviderContribution class in essence is > > what the Map.Entry class already is, the mapped configuration can > > really be leveraged: We can live without the > > ObjectProviderContribution class and remove the contributions > > processing in ObjectTranslator all together. This requires a change > > to the schema rules. We replace: > > > > <schema> > > <element name="provider"> > > <attribute name="prefix" required="true"/> > > <attribute name="service-id" required="true" translator="service"/> > > <conversion > > class="org.apache.hivemind.service.impl.ObjectProviderContribution"> > > <map attribute="service-id" property="provider"/> > > </conversion> > > </element> > > </schema> > > > > with: > > > > <schema> > > <element name="provider" key-attribute="prefix"> > > <attribute name="prefix"/> > > <attribute name="service-id" required="true" translator="service"/> > > <rules> > > <push-attribute attribute="service-id"/> > > <invoke-parent method="addElement"/> > > </rules> > > </element> > > </schema> > > > > Note that the schema hasn't really changed, just the way it's being > > processed. > > > > --knut > > > > On Wed, 17 Nov 2004 13:48:30 +0100, Knut Wannheden > > > > > > <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > This discussion just resurfaced on hivemind-user. So it seems like > > > there are others who'd like to see HiveMind have the possibility to > > > inject configuration contributions as a Map (in addition to List). > > > Also here the idea of adding an additional attribute for this purpose > > > came up. I think there are basically two choices: > > > > > > - <element name="foo" key-attribute="bar"> > > > - <attribute name="bar" key="true"> > > > > > > I suppose both have advantages and disadvantages, but IMHO the > > > attribute on <element> makes more sense. What do others think? > > > > > > --knut > > > > > > On Thu, 28 Oct 2004 06:52:05 -0700, Liebig, Stefan > > > > > > > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > Yes, you are wright, an additional attribute would be much better! > > > > > > > > And again yes, a more "sophisticated" handling of contributions would > > > > also be nice! > > > > > > > > > > > > > > > > compeople AG > > > > Untermainanlage 8 > > > > 60329 Frankfurt > > > > > > > > fon: +49 (69) 272218 - 0 > > > > fax: +49 (69) 272218 - 22 > > > > email: [EMAIL PROTECTED] > > > > home: www.compeople.de > > > > > > > > -----Original Message----- > > > > From: Jean-Francois Poilpret [mailto:[EMAIL PROTECTED] > > > > Sent: Thu 28.10.2004 15:22 > > > > To: [email protected] > > > > Subject: RE: Injecting of Configurations/Contributions > > > > > > > > Hi, > > > > > > > > This seems a good idea to me (I already had this requirement but > > > > finally I > > > > could do without after a big redesign). > > > > However, I don't think that the choice of the key should be based on the > > > > "one attribute that is unique", what if more than one attribute is > > > > unique? > > > > Probably this should be a new property in the schema definition to > > > > indicate > > > > this fact. > > > > > > > > Generally speaking, one common problem with HiveMind configuration > > > > currently > > > > is that whatever the configuration you always get a List injected (same > > > > problem with parameters to factories) > > > > This sounds awkward in particular for cases where the configuration (or > > > > parameters) define exactly one, or (0 or one) occurrences. In this case, > > > > having to call get(0) and cast it to the right Contribution code seems > > > > boring when you have done it a few times... > > > > Maybe having a better injection of Contributions in that case, that > > > > would > > > > directly pass the specific Contribution object (or null if no > > > > contribution > > > > was provided) would be "nice to have". > > > > > > > > Just my 2c. > > > > > > > > -----Original Message----- > > > > From: Liebig, Stefan [mailto:[EMAIL PROTECTED] > > > > Sent: Thursday, October 28, 2004 3:36 PM > > > > To: [email protected] > > > > Subject: Injecting of Configurations/Contributions > > > > > > > > I have very often the case that I have to convert the List of > > > > contributions > > > > into a Map for faster access. In such cases I have always marked a > > > > single > > > > attribute with unique="true". This attribute will get the key of my > > > > Map. The > > > > values will the corresponding contribution elements or their mapping > > > > class. > > > > > > > > I would like to have constructors of services such as: > > > > a) MyServiceOne( Map allContributions ) > > > > > > > > b) MyServiceTwo( List allContributions ) > > > > > > > > for both services their would be a constructor injection such as: > > > > <configuration>AllContributions</configuration> > > > > > > > > In case a) HiveMind should create a Map from �AllContributions� and in > > > > b) a > > > > List. > > > > Creating a Map requieres exactly one attribute/property marked as > > > > unique. > > > > > > > > Do other have similar needs? > > > > > > > > Stefan Liebig > > > > compeople AG > > > > Untermainanlage 8 > > > > 60329 Frankfurt > > > > > > > > fon: +49 (69) 272218 - 0 > > > > fax: +49 (69) 272218 - 22 > > > > email: [EMAIL PROTECTED] > > > > home: www.compeople.de > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- > Howard M. Lewis Ship > Independent J2EE / Open-Source Java Consultant > Creator, Jakarta Tapestry > Creator, Jakarta HiveMind > http://howardlewisship.com > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
