You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by David Solis <ds...@legosoft.com.mx> on 2003/08/04 21:10:11 UTC
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 framework.
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?
Regards
David
RE: Feedback about HiveMind
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
Forgot to say ... thank's for looking at it. I'm actually very jazzed up at the possibilities of
HiveMInd. I think it has the potential to hit a sweet spot in app developement between
quick-and-dirty JSPs and full EJB deployments. You get good decoupling, but it's all in one JVM,
and you miss out on the needless complexity of EJB.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
> -----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
> framework.
>
> 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?
>
> Regards
>
> David
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
RE: Feedback about HiveMind
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
> Howard,
>
> 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.
For the projects I'm using HiveMind on, it is really important that there not be the kind of
"central assembly descriptor" that Avalon has. I'm not familiar with Spring.
To some degree, that constraint works against IoC, since IoC adds the additional layers of
abstraction between components and services (even when the components
are themselves services) that rqeuires an assembly descriptor.
What I saw in Avalon is that you start with a service definition (the interface). You then provide
logical names for each known (at app assembly time) implementation of the service interface. Then
you assign which service implementation is available to which component.
I feel that HiveMind is less heavy handed than Avalon. Through the use of the BuilderFactory, you
can easily assemble instances that have no knowledge of the registry. The module
deployment descriptor will say "set property foo of the implementation to service X, and set
property bar of the implementation to extension point Y". I consider that IoC-lite.
Also, don't miss the extension point aspect, which is the bulk of the code base. This is heavily
derived from Eclipse plugins, but has a few great wrinkles, such as rules-based conversion of XML to
Java POJOs.
>
> 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?
I feel more comfortable with this kind of simplicity vs. IoC simplicity and I like giving people
options. Perhaps HiveMind will evolve into a more IoC centric model.
> 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.
I agree that the best unit testing is where you instantiate your service implementations inside your
test case, and have the test case configure the implementation as if it were the container. I
definately see your point that requiring a container for testing is a problem. I'm still on the
fence, the HiveMind internal test suite uses a mixture of the real container, mock objects, and
direct instantiations.
>
> Regards,
> Colin
>
>
Re: Feedback about HiveMind
Posted by Colin Sampaleanu <co...@exis.com>.
Howard,
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.
Regards,
Colin
Howard M. Lewis Ship wrote:
>I'm just getting started ... sample code and better examples need to wait until HiveMind settles
>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 JAR
>file manifests.
>
>Tapestry today has a number of things that look just like HiveMind services: all those fun
>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
>http://jakarta.apache.org/tapestry
>
>
>
>
>
>>-----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
>>framework.
>>
>>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?
>>
>>Regards
>>
>>David
>>
>>
>>---------------------------------------------------------------------
>>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
>
>
>
RE: Feedback about HiveMind
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
I'm just getting started ... sample code and better examples need to wait until HiveMind settles
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 JAR
file manifests.
Tapestry today has a number of things that look just like HiveMind services: all those fun
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
http://jakarta.apache.org/tapestry
> -----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
> framework.
>
> 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?
>
> Regards
>
> David
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>