Hi, I am continuing to work on the branch to bring the spi model to level with the current specs. One of the key things that I observed is the ability to override various aspects of properties, services and references starting from the ComponentType for an implementation and moving up to ComponentDefinition and then to the Composite.
Looking specifically into references, I understand that targets, interfaces and bindings are among a few other things that can be defined at the ComponentType, then overriden if need in the ComponentDefintion (that uses this component type) and then futher overriden when they are promoted to the Composite. Looking into the SPI model to do this, I feel its best to have separate abstractions instead of one ReferenceDefinition i.e. have ComponentTypeRefDefn, ComponentRefDefn and CompositeRefDefn all of which extends an AbstractRefDefn that encapsulates the commonality in all of this.. such as name, multiplicity, targets, bindings and so on. Though there is vast commonality amongst references at these three levels (componenttype, component, composite) there is also something that is specific to each. For example the 'autorwire' applies only to references in ComponentDefinitions, the 'promote' applies only to 'CompositeReferences'. Thoughts ? Another thing here is about each of these having their own instances of the configurable aspects even if they are not overriding. For example even if the 'bindings' in ComponentTypeReference are not overriden in the ComponentDefnition that uses this componentType, I still copy over all of the 'bindings' in the ComponentTypeReference over to the ComponentDefnReference. I just felt comfortable doing this so that I may avoid one level of indirection when the builder is working around with a ComponentDefn. An alternative would be that wherever the ComponentDefnRef has no overrides, it delegates calls to the underlying ComponentType. For example if the ComponentDefRef does not override bindings and if a builder is looking up its binding, then this lookup call will be delegate to the underlying ComponentType. Opinions ? Since these changes affect the core, far and wide I am about taking sometime to ensure that I don't break consistencies. Thanks - Venkat On 3/15/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
[snip] Venkata Krishnan wrote: > Hi, > > I also see that all our loaders use string literals to load attributes > from > the SCDL for e.g. the name of a component or property and so on. I am > wondering if it would be good to define these as constants somewhere - > for > example attributes related to Property element could be defined in the > Property class / interface of the SPI model or maybe have just one class > that defines all of these model attribute names as constant strings. > > Thanks > Yes good idea, I'd suggest one class for the core assembly model, one class for the policy model, and one for the contribution stuff, roughly mapping each class to an XSD file in the spec XSDs. -- Jean-Sebastien --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
