hivemind-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship (JIRA)" <>
Subject [jira] Commented: (HIVEMIND-130) Chain of command "join points"
Date Mon, 24 Apr 2006 21:31:09 GMT
    [ ] 

Howard M. Lewis Ship commented on HIVEMIND-130:

Another option that occured to me would be to allow multiple <construct> elements when
building a chain of command (using ChainFactory).
Dependencies would be worked out inside each group independently, then the individually ordered
lists would be concatinated to form the final result.
You can kind of simulate this today by having one of the <command> elements reference
a chain-of-command service, but that's at lot of XML to type!

Possibly, implementing <join> and multiple <construct>s would be the most flexible

> Chain of command "join points"
> ------------------------------
>          Key: HIVEMIND-130
>          URL:
>      Project: HiveMind
>         Type: New Feature

>   Components: library
>     Versions: 1.1
>     Reporter: Howard M. Lewis Ship
>     Priority: Minor

> The usefulnes of chain of command could be extended by adding "join points" to the command
chain.  I would define a join point as a no-op command that exists just for ordering other
commands in the chian, i.e.:
> <command id="group-a-1" before="group-b-join" ...>
> <command id="group-a-2" before="group-b-join" ...>
> <join id="group-b-join"/>
> <command id="group-b-1" after="group-b-join" ...>
> <command id="group-b-2" after="group-b-join" ...>
> Of course, the joins themselves shoudl honor before and after attributes.  The joins
become a skeleton, that organize complex command chains into stages.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message