On Aug 16, 2006, at 6:36 AM, Ignacio Silva-Lepe wrote:
There are two issues to consider: (1) how the composite reference
"TargetComponentRef" gets modeled, and (2) how is the composite
reference
"TargetComponentRef" is wired by the wiring infrastructure.
(1) Model and runtime objects for a targetless composite reference. A
targetless composite reference does not have a binding and it is not
specified by a component and given a target. So, at the model level
the
object that represents this kind of composite reference is not a
BoundReferenceDefinition nor a ReferenceTarget, but it can be a plain
ReferenceDefinition instance that is considered separately by
CompositeBuilder to get its runtime representation built. In fact,
ReferenceLoader seems to deal with this case already, returning a
ReferenceDefinition instance when there is no binding, so it's just
a matter
of setting up the CompositeBuilder and registering a builder for the
ReferenceDefinition with the builder registry. At the runtime level
we seem
to have agreed on the definition of a CompositeReference class that
extends
ReferenceExtension. The other piece that is needed is a builder
that creates
a CompositeReference, that is registered with the builder registry
and that
takes a ReferenceDefinition. This can't be a BindingBuilder, so it
seems a
new class is needed, perhaps ReferenceBuilder or
CompositeReferenceBuilder.
Yes this seems right to me. Raymond was preparing to make some
changes to builder dispatching so could you coordinate with him and
I'll apply patches?
(2) Wiring a targetless composite reference. In the example above,
TargetComponentRef does not specify an explicit target or a
binding, its
target is intended to be resolved by a component that is
implemented by the
composite that contains TargetComponentRef, SourceComponent in this
case.
When SourceComponent is being built by CompositeBuilder, a runtime
representation is created for it, e.g., a CompositeComponentImpl.
When an
outbound wire is being added to the created CompositeComponentImpl by
WireService, via the BuilderRegistry, the CompositeComponentImpl
should pass
on this wire to the runtime representation of TargetComponentRef,
i.e.,
CompositeReference. This way, a CompositeComponent "shares" the
outbound
wire of its target with the corresponding CompositeReference. This
way, the
behavior of ConnectorImpl can be to just connect the outbound wire in
SourceComponent's CompositeComponentImpl and not to recurse down into
TargetComponentRef as it is sharing the same wire that was already
connected.
One question that arises is: should passing on wires happen
recursively
down? For instance, since the reference in InnerSourceComponent is
to a
composite reference, should the outbound wire given to the
CompositeComponent that represents InnerSourceComponent come from the
composite reference, i.e., TargetComponentRef?
This brings up some interesting issues. Composite References have
inbound and outbound wires. So in a typical component-->reference
wiring, we have:
component outbound wire--->reference inbound wire--->reference
outbound wire
I think it may be simpler to preserve this as opposed to optimizing
the reference away since multiple components may point to the same
composite reference. So, in the above scenario, it is modeled the
same, with the reference inbound wire being an implementation detail
of the composite:
InnerSourceComponent/OutbindWire---> TargetComponentReference/
InboundWire---> TargetComponentReference/OutboundWire given to the
containing composite and propagated down
The connecting from the inner component to the inner reference would
be done first and then the containing composite would receive the
outbound wire and attach it to the inner reference.
Jim
---------------------------------------------------------------------
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]
