hivemind-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Russell (JIRA)" <>
Subject [jira] Commented: (HIVEMIND-130) Chain of command "join points"
Date Tue, 25 Apr 2006 08:45:07 GMT
    [ ] 

Paul Russell commented on HIVEMIND-130:

I'm not completely convinced that building both wouldn't be overkill. The join point model
you describe in the issue description looks extremely useful, but the multiple <construct>
option is effectively syntactic sugar, as you describe. In fact, I deliberately use the verbose
version of this on one project in order to provide the ability to contribute whole new 'groups'
into the chain from other modules -- using multiple constructs wouldn't allow that flexibility.

That said, if other people think it's a useful way of thinking about it, then I'm more than
happy with that...

> 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