Re: Struts Chain... seams similar to HiveMind ?EOM

2003-10-30 Thread Ted Husted
It's possible that there is some overlap. You might be able to register 
Commands as HiveMind services. But HiveMind has a much broader scope 
than Commons Chain.

Commons Chain is an implementation of the classic Chain of Command 
pattern. Period. It has no other scope or aspirations. People can drop 
it in wherever you might want to implement a Chain of Command. No muss, 
no fuss.

HiveMind is a configuration framework that you could use throughout an 
application and within a Command. You might, for example, register the 
Catalog as a HiveMind service, and the Commands might use HiveMind to 
find the Catalog(s). But, that would be up to the developer. Commons 
Chain does not need to decided how the Catalog is discovered. People 
might also use HiveMind to load the Chain configuration file as an 
alternative to the Digester.

Struts Chain is whiteboard reimplementation of the Request Processor 
using Commons Chain. I don't believe that the Request Processor would be 
easier to implement as a nest of HiveMind services.

-Ted.

Vic Cekvenich wrote:
Struts Chain... seams similar to HiveMind ?
Am I wrong?
.V


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
Ted Husted,
  Junit in Action  - http://www.manning.com/massol/,
  Struts in Action - http://husted.com/struts/book.html,
  JSP Site Design  - http://www.amazon.com/exec/obidos/ISBN=1861005512.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Struts Chain... seams similar to HiveMind ?EOM

2003-10-29 Thread Vic Cekvenich
Struts Chain... seams similar to HiveMind ?
Am I wrong?
.V


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Struts Chain... seams similar to HiveMind ?EOM

2003-10-29 Thread Don Brown
While both concern wiring code together using xml, I think the similarity
ends there.  Hivemind, from my cursory overview, seems more like another
Inversion of Control (IoC) framework like Avalon, PicoContainer, and
Spring.  It is takes services and manages their dependencies and
lifecycle, allowing the developer to organize code as a series of
services.

Struts chain links commands together into to create a process flow.
Commands are very simple objects, like Struts Actions, implementing the
execute() method to perform its tasks.  There is no concept of service
contracts and implementations and all non-primitive dependencies, AFAIK,
are satisifed by putting them in the Context object by a previous command
rather than having the container manage service dependencies.

Since they are solving two different problems, both actually work pretty
good together.  I've been using Spring lately and have found it a great
compliment to a Struts application (http://struts.sf.net/struts-spring).
I'm sure HiveMind would also serve a similar purpose well.

Don

On Wed, 29 Oct 2003, Vic Cekvenich wrote:

 Struts Chain... seams similar to HiveMind ?
 Am I wrong?
 .V



 -
 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]



Re: Struts Chain... seams similar to HiveMind ?EOM

2003-10-29 Thread Martin Cooper
On Wed, 29 Oct 2003, Vic Cekvenich wrote:

 Struts Chain... seams similar to HiveMind ?

If you mean in roughly the same way that apples are similar to oranges,
then I'd agree with you. ;-) Otherwise, no, I don't see similarity.

HiveMind is a services and configuration microkernel or a centralized
registry of services and configuration points, depending on which part of
the home page you read. (It also doesn't have any particular purpose. ;)

Struts Chain is an attempt to refactor the request processor in terms of
the GoF Chain of Responsibility pattern. It's certainly not a microkernel
or a framework of any kind. The chain config itself (which is not part of
Struts Chain per se) could be considered as a registry of sorts, but it's
quite different to what HiveMind's registry is all about.

--
Martin Cooper


 Am I wrong?
 .V



 -
 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]



Re: Struts Chain... seams similar to HiveMind ?EOM

2003-10-29 Thread Vic Cekvenich
But... the chain has a set of steps that are pre-progrmed, and there 
was some discusion as to what those steps should be idealy. Yes, it can 
do return codes but

If HiveMind (or an aproach like it) is used to do the chain, then I can 
easily add interceptors, and alterantice idea for consideration

I found this very educational:
http://jakarta.apache.org/~hlship/HiveMind.ppt
... and based on that I made a leap, that, hey, we can intercept the 
flow. A bit of AOP.
(There are some other ideas in there, like code to the interface contract)

.V



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Struts Chain... seams similar to HiveMind ?EOM

2003-10-29 Thread Don Brown
On Wed, 29 Oct 2003, Vic Cekvenich wrote:

 But... the chain has a set of steps that are pre-progrmed, and there
 was some discusion as to what those steps should be idealy. Yes, it can
 do return codes but

 If HiveMind (or an aproach like it) is used to do the chain, then I can
 easily add interceptors, and alterantice idea for consideration

The chain supports the interceptors as well.  A command can have any
number of commands with each having commands and so on.


 I found this very educational:
 http://jakarta.apache.org/~hlship/HiveMind.ppt

 ... and based on that I made a leap, that, hey, we can intercept the
 flow. A bit of AOP.
 (There are some other ideas in there, like code to the interface contract)

Since you can already intercept the flow with the chain, I don't see
what an IoC, if even applicable, could offer.  Struts needs a composible
process flow that is easily manipulatable and pluggable.  I agree all
those other fancy service-oriented features are nice, but IMO, they belong
in the action/form layer.

Don


 .V



 -
 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]