You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Benjamin Tomasini <bt...@neteverything.com> on 2006/07/31 02:36:58 UTC
Tapestry IoC as a general purpose container
I have been using HiveMind now for quite a while and have come to depend
on it quite heavily on many projects - some web apps, some not. It's
features have very much improved the quality and modularity of my code.
What would prevent a user from employing Tapestry IoC as a general
purpose container like HiveMind? Would there be any benefit to building
one monolithic Tapestry jar and a set of segmented jars (something
Spring does) for more targeted use? Or why not keep Tapestry a single
project with sub-modules for IoC and the Web framework? Alternatively,
what about merging Tapestry IoC and HiveMind at some later date? It
could remain as HiveMind, or it could take on the Tapestry IoC name.
The conversations on this list indicate that key principals of both
projects intend to keep some degree of parity anyway.
Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Tapestry IoC as a general purpose container
Posted by Jesse Kuhnert <jk...@gmail.com>.
Hmmm... Maybe I should start back peddling on being down on James now that
all of this comes to light.
I might need to collaborate with HiveMind when it comes time to try my hand
at providing an extension layer. (I hope the word extension makes it a
magical effort , but more likely than not it will end up looking like a lot
of paper clips and masking tape holding together a very fragile structure :)
)
So, no hard feelings right James? This sounds do-able? ;)
On 7/31/06, Howard Lewis Ship <hl...@gmail.com> wrote:
>
> I'm keeping the package names seperate, to facilitate splitting out
> Tapestry IoC into a standalone project, ala HiveMind. Right now that
> is not a priority.
>
> The way I've been layout out the Tapestry IoC APIs, it should be
> possible to create a kind of bridge RegistryBuilder that can read
> HiveModule XML and make those appear (largely) like native Tapestry
> IoC modules and services. There's a bunch of things that don't line
> up however:
>
> Decorators (service interceptor factories in HiveMind) can now match
> (i.e., target) multiple services. This makes them more like AspectJ
> pointcuts.
>
> Configurations in HiveMind are standalone. In Tapestry IoC each
> service *may* have *one* configuration, as an unordered collection, an
> ordered list, or a map. This turns out to be more than sufficient (you
> can always create a service that exists to vend out its configuration,
> and thus simulate multiple configurations per service).
>
> Object ordering is more robust in Tapestry IoC:
>
> http://tapestry.apache.org/tapestry5/ioc/order.html
>
> Tapestry IoC doesn't yet have a number of HiveMind features:
> - Registry shutdown
> - Pooled service lifecycle model (just "perthread")
> - Object providers (
> http://jakarta.apache.org/hivemind/hivemind/ObjectProviders.html )
> - Symbols
>
> Many features of HiveMind won't be needed in Tapestry IoC as they can
> be more easily accomplished in Java code. Thus "instance:" or
> "class:" object provider prefixes are useless.
>
> On 7/30/06, Benjamin Tomasini <bt...@neteverything.com> wrote:
> > I have been using HiveMind now for quite a while and have come to depend
> > on it quite heavily on many projects - some web apps, some not. It's
> > features have very much improved the quality and modularity of my code.
> >
> > What would prevent a user from employing Tapestry IoC as a general
> > purpose container like HiveMind? Would there be any benefit to building
> > one monolithic Tapestry jar and a set of segmented jars (something
> > Spring does) for more targeted use? Or why not keep Tapestry a single
> > project with sub-modules for IoC and the Web framework? Alternatively,
> > what about merging Tapestry IoC and HiveMind at some later date? It
> > could remain as HiveMind, or it could take on the Tapestry IoC name.
> > The conversations on this list indicate that key principals of both
> > projects intend to keep some degree of parity anyway.
> >
> > Ben
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>
> --
> Howard M. Lewis Ship
> TWD Consulting, Inc.
> Independent J2EE / Open-Source Java Consultant
> Creator and PMC Chair, Apache Tapestry
> Creator, Apache HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work. http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.
Re: Tapestry IoC as a general purpose container
Posted by Howard Lewis Ship <hl...@gmail.com>.
I'm keeping the package names seperate, to facilitate splitting out
Tapestry IoC into a standalone project, ala HiveMind. Right now that
is not a priority.
The way I've been layout out the Tapestry IoC APIs, it should be
possible to create a kind of bridge RegistryBuilder that can read
HiveModule XML and make those appear (largely) like native Tapestry
IoC modules and services. There's a bunch of things that don't line
up however:
Decorators (service interceptor factories in HiveMind) can now match
(i.e., target) multiple services. This makes them more like AspectJ
pointcuts.
Configurations in HiveMind are standalone. In Tapestry IoC each
service *may* have *one* configuration, as an unordered collection, an
ordered list, or a map. This turns out to be more than sufficient (you
can always create a service that exists to vend out its configuration,
and thus simulate multiple configurations per service).
Object ordering is more robust in Tapestry IoC:
http://tapestry.apache.org/tapestry5/ioc/order.html
Tapestry IoC doesn't yet have a number of HiveMind features:
- Registry shutdown
- Pooled service lifecycle model (just "perthread")
- Object providers (
http://jakarta.apache.org/hivemind/hivemind/ObjectProviders.html )
- Symbols
Many features of HiveMind won't be needed in Tapestry IoC as they can
be more easily accomplished in Java code. Thus "instance:" or
"class:" object provider prefixes are useless.
On 7/30/06, Benjamin Tomasini <bt...@neteverything.com> wrote:
> I have been using HiveMind now for quite a while and have come to depend
> on it quite heavily on many projects - some web apps, some not. It's
> features have very much improved the quality and modularity of my code.
>
> What would prevent a user from employing Tapestry IoC as a general
> purpose container like HiveMind? Would there be any benefit to building
> one monolithic Tapestry jar and a set of segmented jars (something
> Spring does) for more targeted use? Or why not keep Tapestry a single
> project with sub-modules for IoC and the Web framework? Alternatively,
> what about merging Tapestry IoC and HiveMind at some later date? It
> could remain as HiveMind, or it could take on the Tapestry IoC name.
> The conversations on this list indicate that key principals of both
> projects intend to keep some degree of parity anyway.
>
> Ben
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
RE: Tapestry IoC as a general purpose container
Posted by James Carman <ja...@carmanconsulting.com>.
HiveMind is going to incorporate some of the same concepts as Tapestry IoC.
We are actively discussing the future of HiveMind and its goals. I'm glad
to hear you use HiveMind and find it very helpful to you. If you have any
suggestions or features that you want in HiveMind, please shoot an email
over to the HiveMind developers list for discussion (the lists have moved
recently since we're going to be a top-level project soon). You can be sure
that we'll be peeking over Howard's shoulder to "borrow" some of his ideas
from Tapestry IoC for HiveMind! :-)
-----Original Message-----
From: Benjamin Tomasini [mailto:btomasini@neteverything.com]
Sent: Sunday, July 30, 2006 8:37 PM
To: dev@tapestry.apache.org
Subject: Tapestry IoC as a general purpose container
I have been using HiveMind now for quite a while and have come to depend
on it quite heavily on many projects - some web apps, some not. It's
features have very much improved the quality and modularity of my code.
What would prevent a user from employing Tapestry IoC as a general
purpose container like HiveMind? Would there be any benefit to building
one monolithic Tapestry jar and a set of segmented jars (something
Spring does) for more targeted use? Or why not keep Tapestry a single
project with sub-modules for IoC and the Web framework? Alternatively,
what about merging Tapestry IoC and HiveMind at some later date? It
could remain as HiveMind, or it could take on the Tapestry IoC name.
The conversations on this list indicate that key principals of both
projects intend to keep some degree of parity anyway.
Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org