Leo Sutic wrote:
> 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.
First, I am in the process of separating out the Container and
ComponentManager/Selector interfaces. This also allows the ability to
use the new ServiceManager interfaces instead of the ComponentManager
interfaces.
Second, what you are proposing is not out of the question. There are
different ways that it can be accomplished though.
BTW, I don't like the Rolemanageable/LogKitManageable interfaces, and
prefer to pass references via the Context.
> The code for this is also very useful for any other
> Component-that-has-subComponents.
And don't forget Containers that have Containers!
> 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.
However, you are referring to a situation where you have a very small
number of components. If your heirarchical component structure directly
used the handler classes, you should be good to go.
>
> 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.
In this situation, you have to wonder if you need full components, or
simple decision objects. But that is neither here nor there.
Basically, the Root decision object/component has one component, and
one answer has another decision component.
>
> 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>
All you need to do in each of these cases is use them like the
interpreted sitemap in Cocoon.
You're root component can recursively use the decision method
(lighter than a whole component) to get down to the final
decision. The method would look something like this:
Action getAction(Context c, Configuration rules)
{
if ( !rules.getName().equals("rule") )
{
throw new IllegalStateException( "No rules specified" );
}
Rule = (Rule) m_ruleSelector.select(rules.getAttribute("class"));
Configuration[] when = rules.getChildren("when");
for (int i = 0; i < when.length; i++)
{
if ( rule.inRange( c,
when[i].getAttribute("start"),
when[i].getAttribute("end") ) )
{
Configuration result = when[i].getChild();
if (result.getName().equals("rule"))
{
return getAction( c, result );
}
else
{
return (Action) m_actionSelector.select(
result.getAttribute( "class" ) );
}
}
}
}
>
> 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"/>
You don't have to flatten the configuration, if you interpret it on the
fly.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
