I forgot to mention that the SchemaProcessor gets its reference to the key attribute *name* (not the value) from the current SchemaElement, which in turn gets it from the ElementModel it corresponds to.
--knut On Tue, 23 Nov 2004 21:20:38 +0100, Knut Wannheden <[EMAIL PROTECTED]> wrote: > 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 > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
