All, there is a lot of code duplicated between the ExcaliburComponentManager and the ExcaliburComponentSelector. Basically, they both implement Contextualizable, Composable (ECM only), RoleManageable and LogKitManageable. These interfaces are just implemented in order to pass on the context etc. to the ComponentHandlers.
The code for this is also very useful for any other
Component-that-has-subComponents.
My example is this:
I have a component that will use the strategy pattern. That is, it has a
method
that is something like this:
public Action whatToDoNext (Context context);
So, given something, it will return an action for the context. Now comes
the fun part: It solves this by having another component within itself
that it passes the context on to and recieves an Action in return.
*That* component may in turn have sub-components.
So, I end up with a decision tree where the nodes are components.
For example, suppose we want to do A in the afternoon and B otherwise, with
the exception that instead of B, we should do C on Sundays.
Sunday +--------------- C
|
AM +-------- DayOfWeek ---------- B
| Otherw.
Root ---- TimeOfDay
|
PM +--------- A
Each node in the tree would be a component, that could possibly have
subcomponents.
The configuration would look like this:
<tree-root>
<rule class="TimeOfDay">
<when start="0" end="12">
<rule class="DayOfWeek">
<when start="Monday" end="Saturday">
<action class="B"/>
</when>
<when start="Sunday" end="Sunday">
<action class="C"/>
</when>
</rule>
</when>
<when start="12" end="24">
<action class="A"/>
</when>
</rule>
</tree-root>
In Cocoon this is solved by looking up the matchers (equivalent to the
DayOfWeek and
TimeOfDay classes in the example) via a ComponentSelector, and passing a
pattern
to them. This is suboptimal when each component instance in the selector
is only used in one place and I would end up with the following instances in
the Selector:
<rule hint="root" class="TimeOfDay">
<when start="0" end="12" then="day-of-week"/>
<when start="12" end="24" then="A"/>
</rule>
<rule hint="day-of-week" class="DayOfWeek">
<when start="Monday" end="Saturday" then="B"/>
<when start="Sunday" end="Sunday" then="C"/>
</rule>
<rule hint="A" class="FireA"/>
<rule hint="B" class="FireB"/>
<rule hint="C" class="FireC"/>
Of course, if we want to select between weekdays in another part of the
tree - say, do D instead of A on Saturdays, we get an additional:
<rule hint="day-of-week-saturday" class="DayOfWeek">
<when start="Sunday" end="Friday" then="A"/>
<when start="Saturday" end="Saturday" then="D"/>
</rule>
(And don't forget to update the hint="root" rule to reference this new
rule!)
And so on. As the tree gets flattened, maintainability is lost, and I would
like
to solve this by allowing each component to have sub-components, just like a
ComponentSelector can select among several sub-Selectors.
This would also allow for powerful rule-based ComponentSelectors to do
N-dimensional
lookups, where the rules need not be coded into the ComponentSelector.
THE PROPOSAL:
Attached is an implementation of AbstractContainer and
ExcaliburComponentManager,
modified to inherit from AbstractContainer.
The AbstractContainer class gathers all the references necessary to create
ComponentHandlers - it does nothing more. What happens with the handlers
is up to the subclass.
I propose that this replace the current implementation of ECM, that the ECS
is rewritten to derive from AbstractContainer, and that AbstractContainer
is make part of Excalibur.
I am not calling a vote just yet.
I am also looking for input regarding:
- What is the opinion regarding components-that-have-components in Avalon?
Is this a no-no, with the exception of ComponentSelector?
/LS
AbstractContainer.java
Description: JavaScript source
ExcaliburComponentManager.java
Description: JavaScript source
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
