RE: HiveMind feedback/questions

["Howard M. Lewis Ship" <hl...@comcast.net>]

Mixing and matching technologies is very cool.  Some comments I made at the TSS were noted by the
Spring guys ... they are interested in adding line precise error reporting to Spring. Obviously, I
prefer HiveMind, and I'll continue to produce case studies to show why.  Spring has a huge head
start in terms of components/services already packaged, which will be the growth area for HiveMind.

I really think HiveMind has found a sweet spot where you can get a lot accomplished with very little
code ... and very little XML. I'll take another look at Spring when I have a chance, but I don't
think the distributed configuration aspects of HiveMind are anywhere else, outside of Eclipse
plugins ... and the "digester-lite" stuff shouldn't be discounted either.  Woops ... started
preaching there.

Anyway, that Tapestry+Spring doc is pretty darn cool.  We want Tacos to contain working examples
along those lines, templates for all kinds of projects. Hasn't happened yet ... still looking for
some leadership I guess. Soon.

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com

> -----Original Message-----
> From: Colin Sampaleanu [mailto:colinml1@exis.com] 
> Sent: Thursday, September 11, 2003 6:03 PM
> To: Tapestry development; 
> springframework-developer@lists.sourceforge.net
> Subject: Re: HiveMind feedback/questions
> 
> 
> Anybody in the Tapestry world who finds HiveMind 
> (http://jakarta.apache.org/commons/sandbox/hivemind/) 
> interesting should 
> probably also take a good look at Spring Framework 
> (http://www.springframework.org/). I am unfortunately much 
> more familiar 
> with Spring than with HiveMind, so it wouldn't be fair for me 
> to try to 
> qualify which containter I think is 'better' (and an 
> assertion like this 
> is usually relative to the use-case anyways), but I think anybody can 
> learn a lot by looking at both approaches. While the gross 
> functionality 
> is pretty similar, there are of course some fundamental 
> differences in 
> the approaches taken to implementation, configuration, and usage.
> 
> Along with the container services, Spring does include a lot of other 
> things, such as integration into the container and 
> interceptor framework 
> of a JDBC abstraction layer, some Hibernate support code, 
> transactional 
> wrapping, etc. There is also a UI layer which I haven't used 
> so far as I 
> prefer Tapestry.
> 
> A couple of weeks ago I wrote an article on intergrating 
> Tapestry with 
> Spring. It does assume you are already familiar with both frameworks 
> however. It's available at:
>   http://www.springframework.org/docs/integration/tapestry.html
> 
> Regards,
> Colin
> 
> 
> Harish Krishnaswamy wrote:
> 
> > I put the Adder example together with a LoggingInterceptor in three
> > modules and its pretty slick. Although the free form schema gets my 
> > head spinning ;). I think it'll take a little bit to get 
> adjusted to 
> > living without constraints! I like the fact that it can 
> support both 
> > IoC and SoC, nice! And the documentation is great.
> >
> > I have a few questions:
> > 1. What is rationale behind the names <service...> and
> > <extension-point...>? That would probably clarify my confusion with 
> > the names. It got me a little confused initially, 
> > <service-extension-point...> and 
> <config-extension-point...> is more 
> > intuitive to me.
> > 2. How to debug deferred services when dynamic proxies are used?
> > 3. In the BuilderFactory which service extension point id 
> gets stored 
> > in the point-id-property? For example, if I use a 
> LoggingInterceptor 
> > like...
> >  <extend-service service-id="hivemind.examples.Adder">
> >    <interceptor service-id="hivemind.LoggingInterceptor" 
> order="10"/>
> >  </extend-service>
> >
> > Thanks,
> > Harish
> >
> >
> >
> > 
> ---------------------------------------------------------------------
> > 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
>