tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colin Sampaleanu <colin...@exis.com>
Subject Re: Feedback about HiveMind
Date Mon, 04 Aug 2003 20:46:33 GMT

I've taken a bit of a look at HiveMind. Looks pretty interestings! I do 
have a comment about the general approach, after having spent some 
fairly serious time with the SpringFramework 
(http://www.springframework.org) over the last 3 weeks or so, and a 
while ago having spent some time with Avalon.

In some respects, the Spring ApplicationContext and the HiveMind 
registry serve the same purposes, and can both be used in similar 
fashions. However, the Spring guys _really_ push the use of the 
ApplicationContext in an IOC (Inversion of Control, for those who don't 
know the acronym) fashion, if at all possible, and I have to say I 
fundamentally feel this is the right approach most of the time. In that 
respect, one or more Spring ApplicationContext implementations can be 
responsible for wiring up and supplying almost all the objects in the 
system (which need to be dynamically wired, obviously some stuff is 
better left to new), but generally when using IOC almost none of those 
objects need to know about the ApplicationContext.

Now looking at your documentation for HiveMind, while there is as far as 
I can tell nothing stopping you from using HiveMind in an IOC fashion, 
it seems you are pushing it's use more in the 'central registry' 
fashion, where a lot of the users of the registry actually know about 
it. To quote:

"""You code is responsible for:

    * Obtaining a reference to the registry singleton
    * Knowing the name of the service to access
    * Passing in the class for the interface"""

I'm curious if in fact this is the main way you see it used, and where 
you think the advantages are? From my experience, what I _really_ like 
about the IOC approach is that there is no real dependence on the 
container itself, and testing becomes much easier. If an object knows 
about the container on the other hand, testing it involves at least a 
mock container. In the approach above, for example, having a registry 
singleton makes swapping out one implementaiton for another 
significantly harder, when you need to do it one way for one test, 
another way for another test, etc.


Howard M. Lewis Ship wrote:

>I'm just getting started ... sample code and better examples need to wait until HiveMind
>down a bit.  I'm feeling that it's just about there.  I'm actually using HiveMind at work,
so I'm
>seeing and fixing the rough edges.
>An important aspect of HiveMind is that it work properly inside an EAR deployment.  I
haven't fully
>tested, but I believe it does ... that's why it includes the necessary Ant tasks for creating
>file manifests.
>Tapestry today has a number of things that look just like HiveMind services: all those
>interfaces available through the engine.  In Tap3.0 to override those implementations,
you'll have
>to subclass BaseEngine; in Tap3.1 you'll override the default service implementation.
>Howard M. Lewis Ship
>Creator, Tapestry: Java Web Components
>>-----Original Message-----
>>From: David Solis [mailto:dsolis@legosoft.com.mx] 
>>Sent: Monday, August 04, 2003 3:10 PM
>>To: 'Tapestry development'
>>Subject: Feedback about HiveMind
>>As I expected, HiveMind framework looks very well designed, 
>>also its documentation is good. But, why not to include some 
>>sample code to clarify some of the framework features?
>>HiveMind could provide several benefits to an application or 
>>Possible Tapestry benefits:
>>+ Configuration issues
>>+ Custom rendering services
>>+ Logging
>>Are there other possible uses?
>>I was wondering about how to integrate it within an app server?
>>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

View raw message