You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2007/03/09 16:42:47 UTC
Simplify Tapestry IoC?
I've been giving some thought towards simplifying Tapestry 5 IOC.
I'm beginning to question the value of having a segmented namespace.
Let me clarify; I think there are situations, if and when you have
large (dozens) of modules, where a segmented namespace is valuable.
However, in the typical case (a normal Tapestry application with a
component library or two) it is unlikely that naming will get that
complicated, and having simple naming is easier to understand.
This would eliminate the @Id annotation on module builders (they
wouldn't need IDs at all). I believe the @Contribute annotation would
also go (you would always be able to identify the service to
contribute to directly from the method name). There's a lot of other
logic, related to things like ordering, decorating, and service
matching (GlobMatcher) as well that would simplify.
--
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: Simplify Tapestry IoC?
Posted by Jesse Kuhnert <jk...@gmail.com>.
Sounds like good stuff to me!
btw, any interceptions I made this morning had nothing to do with my
opinions of differing impl's....There was maybe one pretty good
improvement in there and that's about it. ...You are king of IoC and
if people don't know it we'll have to find a way to get that out. ;)
On 3/9/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> I'm liking how this is coming out. A bunch of things are simpler and
> will be easier to describe and implement, and more importantly, I have
> a strong intuition the flat name space will be easier for end users to
> understand (especially if they have looked at Spring).
>
> On 3/9/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> > that's the *intent*
> >
> > My fingers have a mind of their own. They, too, Just Work (tm).
> >
> > On 3/9/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> > > Yep, that's the inject ... it should Just Work (tm).
> > >
> > > On 3/9/07, Jesse Kuhnert <jk...@gmail.com> wrote:
> > > > Oh, I didn't mean to point out autowiring as an example of how T5
> > > > @Inject is bad or anything, just more around the point of having to
> > > > specify the service id. If I could have @Inject without having to give
> > > > it an ID that would be much preferrable. (and would avoid all of my
> > > > little /* injected */ comments above them as they'd be self
> > > > documenting )
> > > >
> > > > On 3/9/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> > > > > Well, @Inject in T5 is very smart; its a chain-of-command (and
> > > > > extensible) that can try a bunch of different things; with an Asset
> > > > > field, the annotation value is the path to the asset, with a Block
> > > > > field, the annotation value is the id of the block, with a bunch of
> > > > > pre-determined types, it just knows what to do, and for everything
> > > > > else, it looks for a unique service with the matching service
> > > > > interface.
> > > > >
> > > > > On 3/9/07, Jesse Kuhnert <jk...@gmail.com> wrote:
> > > > > > +1
> > > > > >
> > > > > > It's definitely worth exploring...I guess you are starting to have
> > > > > > enough code sitting around now to test the theory against. (spring /
> > > > > > hibernate)
> > > > > >
> > > > > > I do have to admit that I almost never use @InjectObject now with the
> > > > > > autowire stuff built in from James. Not exactly the same thing totally
> > > > > > but it is similar enough to draw some sort of opinion from.
> > > > > >
> > > > > > On 3/9/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> > > > > > > I've been giving some thought towards simplifying Tapestry 5 IOC.
> > > > > > >
> > > > > > > I'm beginning to question the value of having a segmented namespace.
> > > > > > >
> > > > > > > Let me clarify; I think there are situations, if and when you have
> > > > > > > large (dozens) of modules, where a segmented namespace is valuable.
> > > > > > > However, in the typical case (a normal Tapestry application with a
> > > > > > > component library or two) it is unlikely that naming will get that
> > > > > > > complicated, and having simple naming is easier to understand.
> > > > > > >
> > > > > > > This would eliminate the @Id annotation on module builders (they
> > > > > > > wouldn't need IDs at all). I believe the @Contribute annotation would
> > > > > > > also go (you would always be able to identify the service to
> > > > > > > contribute to directly from the method name). There's a lot of other
> > > > > > > logic, related to things like ordering, decorating, and service
> > > > > > > matching (GlobMatcher) as well that would simplify.
> > > > > > >
> > > > > > > --
> > > > > > > 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
> > > > > > Tapestry/Dojo team member/developer
> > > > > >
> > > > > > Open source based consulting work centered around
> > > > > > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > 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
> > > > Tapestry/Dojo team member/developer
> > > >
> > > > Open source based consulting work centered around
> > > > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
> > >
> >
> >
> > --
> > 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
> >
>
>
> --
> 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
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Simplify Tapestry IoC?
Posted by Massimo Lusetti <ml...@gmail.com>.
hOn 3/10/07, Ben Sommerville <be...@bulletproof.com.au> wrote:
> I'm a little concerned by this change. Not saying it is a bad idea, just
> that for me, there seem to be more drawbacks than benefits.
That's right in the scope of a big organization of a long and wide
reused components/modules/services.
> Granted, I'm pretty sure I'm not a "typical" end user of tapestry. And
> I haven't really used Spring either (which I assume from your comment also
> has a flat namespace), so I don't know how it works there.
Yes, you're right again.
Spring as a flat namespace and it is considered the de-facto standard
for IoC framework.
> I agree that if you are just using Tapestry then a flat namespace is
> simpler. However I think as soon as you want to support third party
> libraries then IMHO, it is starting on a slippery slope.
That's my point. If you start using T5 IoC as a core framework in
different (type of) application that's probably lies the slippery.
But maybe the future trend or say the current direction is to have an
external application service injected within T5 using some sort of
bridge (as i like to call them) T5 module which act as ObjectProvider
for T5 pages/services.
In T4 times i 'married' HiveMind and built my applications around it,
it has been great and it is greater that i can reuse my old modules
with not so much effort.
> For handling injection of services, I guess Tapestry can make the issue
> transparent by resolving the service based on the requested type.
>
> But for contributing to services I don't think is possible (cause the
> contribution point doesn't necessarily have to refer to any type associated
> with the service).
>
>
> I have been very impressed with the IOC container in my explorations thus
> far & I would like to use it for more than just Tapestry configuration. I
> like how easy it is to create new modules/services and package them into
> libraries for reuse.
That's one of the great feature that comes directly from HiveMind
experience. It has saved me a lot of deploy effort so many times.
> A namespacing mechanism is, IMHO, an important part of easily packaging &
> reusing shared services. If the container doesn't support namespacing
> directly
> then I suspect that we'll end up with a libraries using a standard prefix
> for
> their servcies. i.e. 'Foo' library would have services like 'fooOne',
> 'fooTwo',
> 'fooThree', etc.
Maybe some sort of convention around configuration applied to names? :)
> Is it possible to have the best of both worlds?
> For example, keep the segmented namespace but allow name resolution across
> all segments if the name is not explicitly qualified?
Someone told that @Inject Just Works (TM) so i guess it will just works :)
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
RE: Simplify Tapestry IoC?
Posted by Ben Sommerville <be...@bulletproof.com.au>.
I'm a little concerned by this change. Not saying it is a bad idea, just
that for me, there seem to be more drawbacks than benefits.
Granted, I'm pretty sure I'm not a "typical" end user of tapestry. And
I haven't really used Spring either (which I assume from your comment also
has a flat namespace), so I don't know how it works there.
I agree that if you are just using Tapestry then a flat namespace is
simpler. However I think as soon as you want to support third party
libraries then IMHO, it is starting on a slippery slope.
My main concern is: What happens if two libraries have a service
with the same name?
Does the first one win?
Does Tapestry refuse to load?
What options does the end user have?
(assume they cannot easily change one of the names)
For handling injection of services, I guess Tapestry can make the issue
transparent by resolving the service based on the requested type.
But for contributing to services I don't think is possible (cause the
contribution point doesn't necessarily have to refer to any type associated
with the service).
I have been very impressed with the IOC container in my explorations thus
far & I would like to use it for more than just Tapestry configuration. I
like how easy it is to create new modules/services and package them into
libraries for reuse.
A namespacing mechanism is, IMHO, an important part of easily packaging &
reusing shared services. If the container doesn't support namespacing
directly
then I suspect that we'll end up with a libraries using a standard prefix
for
their servcies. i.e. 'Foo' library would have services like 'fooOne',
'fooTwo',
'fooThree', etc.
Is it possible to have the best of both worlds?
For example, keep the segmented namespace but allow name resolution across
all segments if the name is not explicitly qualified?
regards,
Ben
> -----Original Message-----
> From: Howard Lewis Ship [mailto:hlship@gmail.com]
> Sent: Saturday, 10 March 2007 2:07 PM
> To: Tapestry development
> Subject: Re: Simplify Tapestry IoC?
>
> I'm liking how this is coming out. A bunch of things are
> simpler and will be easier to describe and implement, and
> more importantly, I have a strong intuition the flat name
> space will be easier for end users to understand (especially
> if they have looked at Spring).
>
> On 3/9/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> > that's the *intent*
> >
> > My fingers have a mind of their own. They, too, Just Work (tm).
> >
> > On 3/9/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> > > Yep, that's the inject ... it should Just Work (tm).
> > >
> > > On 3/9/07, Jesse Kuhnert <jk...@gmail.com> wrote:
> > > > Oh, I didn't mean to point out autowiring as an example
> of how T5
> > > > @Inject is bad or anything, just more around the point
> of having
> > > > to specify the service id. If I could have @Inject
> without having
> > > > to give it an ID that would be much preferrable. (and
> would avoid
> > > > all of my little /* injected */ comments above them as
> they'd be
> > > > self documenting )
> > > >
> > > > On 3/9/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> > > > > Well, @Inject in T5 is very smart; its a chain-of-command (and
> > > > > extensible) that can try a bunch of different things;
> with an
> > > > > Asset field, the annotation value is the path to the
> asset, with
> > > > > a Block field, the annotation value is the id of the
> block, with
> > > > > a bunch of pre-determined types, it just knows what
> to do, and
> > > > > for everything else, it looks for a unique service with the
> > > > > matching service interface.
> > > > >
> > > > > On 3/9/07, Jesse Kuhnert <jk...@gmail.com> wrote:
> > > > > > +1
> > > > > >
> > > > > > It's definitely worth exploring...I guess you are
> starting to
> > > > > > have enough code sitting around now to test the theory
> > > > > > against. (spring /
> > > > > > hibernate)
> > > > > >
> > > > > > I do have to admit that I almost never use
> @InjectObject now
> > > > > > with the autowire stuff built in from James. Not
> exactly the
> > > > > > same thing totally but it is similar enough to draw
> some sort of opinion from.
> > > > > >
> > > > > > On 3/9/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> > > > > > > I've been giving some thought towards simplifying
> Tapestry 5 IOC.
> > > > > > >
> > > > > > > I'm beginning to question the value of having a
> segmented namespace.
> > > > > > >
> > > > > > > Let me clarify; I think there are situations, if and when
> > > > > > > you have large (dozens) of modules, where a
> segmented namespace is valuable.
> > > > > > > However, in the typical case (a normal Tapestry
> application
> > > > > > > with a component library or two) it is unlikely
> that naming
> > > > > > > will get that complicated, and having simple
> naming is easier to understand.
> > > > > > >
> > > > > > > This would eliminate the @Id annotation on module
> builders
> > > > > > > (they wouldn't need IDs at all). I believe the
> @Contribute
> > > > > > > annotation would also go (you would always be able to
> > > > > > > identify the service to contribute to directly from the
> > > > > > > method name). There's a lot of other logic, related to
> > > > > > > things like ordering, decorating, and service
> matching (GlobMatcher) as well that would simplify.
> > > > > > >
> > > > > > > --
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Simplify Tapestry IoC?
Posted by Howard Lewis Ship <hl...@gmail.com>.
I'm liking how this is coming out. A bunch of things are simpler and
will be easier to describe and implement, and more importantly, I have
a strong intuition the flat name space will be easier for end users to
understand (especially if they have looked at Spring).
On 3/9/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> that's the *intent*
>
> My fingers have a mind of their own. They, too, Just Work (tm).
>
> On 3/9/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> > Yep, that's the inject ... it should Just Work (tm).
> >
> > On 3/9/07, Jesse Kuhnert <jk...@gmail.com> wrote:
> > > Oh, I didn't mean to point out autowiring as an example of how T5
> > > @Inject is bad or anything, just more around the point of having to
> > > specify the service id. If I could have @Inject without having to give
> > > it an ID that would be much preferrable. (and would avoid all of my
> > > little /* injected */ comments above them as they'd be self
> > > documenting )
> > >
> > > On 3/9/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> > > > Well, @Inject in T5 is very smart; its a chain-of-command (and
> > > > extensible) that can try a bunch of different things; with an Asset
> > > > field, the annotation value is the path to the asset, with a Block
> > > > field, the annotation value is the id of the block, with a bunch of
> > > > pre-determined types, it just knows what to do, and for everything
> > > > else, it looks for a unique service with the matching service
> > > > interface.
> > > >
> > > > On 3/9/07, Jesse Kuhnert <jk...@gmail.com> wrote:
> > > > > +1
> > > > >
> > > > > It's definitely worth exploring...I guess you are starting to have
> > > > > enough code sitting around now to test the theory against. (spring /
> > > > > hibernate)
> > > > >
> > > > > I do have to admit that I almost never use @InjectObject now with the
> > > > > autowire stuff built in from James. Not exactly the same thing totally
> > > > > but it is similar enough to draw some sort of opinion from.
> > > > >
> > > > > On 3/9/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> > > > > > I've been giving some thought towards simplifying Tapestry 5 IOC.
> > > > > >
> > > > > > I'm beginning to question the value of having a segmented namespace.
> > > > > >
> > > > > > Let me clarify; I think there are situations, if and when you have
> > > > > > large (dozens) of modules, where a segmented namespace is valuable.
> > > > > > However, in the typical case (a normal Tapestry application with a
> > > > > > component library or two) it is unlikely that naming will get that
> > > > > > complicated, and having simple naming is easier to understand.
> > > > > >
> > > > > > This would eliminate the @Id annotation on module builders (they
> > > > > > wouldn't need IDs at all). I believe the @Contribute annotation would
> > > > > > also go (you would always be able to identify the service to
> > > > > > contribute to directly from the method name). There's a lot of other
> > > > > > logic, related to things like ordering, decorating, and service
> > > > > > matching (GlobMatcher) as well that would simplify.
> > > > > >
> > > > > > --
> > > > > > 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
> > > > > Tapestry/Dojo team member/developer
> > > > >
> > > > > Open source based consulting work centered around
> > > > > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > 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
> > > Tapestry/Dojo team member/developer
> > >
> > > Open source based consulting work centered around
> > > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
>
>
> --
> 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
>
--
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: Simplify Tapestry IoC?
Posted by Howard Lewis Ship <hl...@gmail.com>.
that's the *intent*
My fingers have a mind of their own. They, too, Just Work (tm).
On 3/9/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> Yep, that's the inject ... it should Just Work (tm).
>
> On 3/9/07, Jesse Kuhnert <jk...@gmail.com> wrote:
> > Oh, I didn't mean to point out autowiring as an example of how T5
> > @Inject is bad or anything, just more around the point of having to
> > specify the service id. If I could have @Inject without having to give
> > it an ID that would be much preferrable. (and would avoid all of my
> > little /* injected */ comments above them as they'd be self
> > documenting )
> >
> > On 3/9/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> > > Well, @Inject in T5 is very smart; its a chain-of-command (and
> > > extensible) that can try a bunch of different things; with an Asset
> > > field, the annotation value is the path to the asset, with a Block
> > > field, the annotation value is the id of the block, with a bunch of
> > > pre-determined types, it just knows what to do, and for everything
> > > else, it looks for a unique service with the matching service
> > > interface.
> > >
> > > On 3/9/07, Jesse Kuhnert <jk...@gmail.com> wrote:
> > > > +1
> > > >
> > > > It's definitely worth exploring...I guess you are starting to have
> > > > enough code sitting around now to test the theory against. (spring /
> > > > hibernate)
> > > >
> > > > I do have to admit that I almost never use @InjectObject now with the
> > > > autowire stuff built in from James. Not exactly the same thing totally
> > > > but it is similar enough to draw some sort of opinion from.
> > > >
> > > > On 3/9/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> > > > > I've been giving some thought towards simplifying Tapestry 5 IOC.
> > > > >
> > > > > I'm beginning to question the value of having a segmented namespace.
> > > > >
> > > > > Let me clarify; I think there are situations, if and when you have
> > > > > large (dozens) of modules, where a segmented namespace is valuable.
> > > > > However, in the typical case (a normal Tapestry application with a
> > > > > component library or two) it is unlikely that naming will get that
> > > > > complicated, and having simple naming is easier to understand.
> > > > >
> > > > > This would eliminate the @Id annotation on module builders (they
> > > > > wouldn't need IDs at all). I believe the @Contribute annotation would
> > > > > also go (you would always be able to identify the service to
> > > > > contribute to directly from the method name). There's a lot of other
> > > > > logic, related to things like ordering, decorating, and service
> > > > > matching (GlobMatcher) as well that would simplify.
> > > > >
> > > > > --
> > > > > 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
> > > > Tapestry/Dojo team member/developer
> > > >
> > > > Open source based consulting work centered around
> > > > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
> > Tapestry/Dojo team member/developer
> >
> > Open source based consulting work centered around
> > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
> >
> > ---------------------------------------------------------------------
> > 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
>
--
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: Simplify Tapestry IoC?
Posted by Howard Lewis Ship <hl...@gmail.com>.
Yep, that's the inject ... it should Just Work (tm).
On 3/9/07, Jesse Kuhnert <jk...@gmail.com> wrote:
> Oh, I didn't mean to point out autowiring as an example of how T5
> @Inject is bad or anything, just more around the point of having to
> specify the service id. If I could have @Inject without having to give
> it an ID that would be much preferrable. (and would avoid all of my
> little /* injected */ comments above them as they'd be self
> documenting )
>
> On 3/9/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> > Well, @Inject in T5 is very smart; its a chain-of-command (and
> > extensible) that can try a bunch of different things; with an Asset
> > field, the annotation value is the path to the asset, with a Block
> > field, the annotation value is the id of the block, with a bunch of
> > pre-determined types, it just knows what to do, and for everything
> > else, it looks for a unique service with the matching service
> > interface.
> >
> > On 3/9/07, Jesse Kuhnert <jk...@gmail.com> wrote:
> > > +1
> > >
> > > It's definitely worth exploring...I guess you are starting to have
> > > enough code sitting around now to test the theory against. (spring /
> > > hibernate)
> > >
> > > I do have to admit that I almost never use @InjectObject now with the
> > > autowire stuff built in from James. Not exactly the same thing totally
> > > but it is similar enough to draw some sort of opinion from.
> > >
> > > On 3/9/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> > > > I've been giving some thought towards simplifying Tapestry 5 IOC.
> > > >
> > > > I'm beginning to question the value of having a segmented namespace.
> > > >
> > > > Let me clarify; I think there are situations, if and when you have
> > > > large (dozens) of modules, where a segmented namespace is valuable.
> > > > However, in the typical case (a normal Tapestry application with a
> > > > component library or two) it is unlikely that naming will get that
> > > > complicated, and having simple naming is easier to understand.
> > > >
> > > > This would eliminate the @Id annotation on module builders (they
> > > > wouldn't need IDs at all). I believe the @Contribute annotation would
> > > > also go (you would always be able to identify the service to
> > > > contribute to directly from the method name). There's a lot of other
> > > > logic, related to things like ordering, decorating, and service
> > > > matching (GlobMatcher) as well that would simplify.
> > > >
> > > > --
> > > > 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
> > > Tapestry/Dojo team member/developer
> > >
> > > Open source based consulting work centered around
> > > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
> > >
> > > ---------------------------------------------------------------------
> > > 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
> Tapestry/Dojo team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>
> ---------------------------------------------------------------------
> 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: Simplify Tapestry IoC?
Posted by Jesse Kuhnert <jk...@gmail.com>.
Oh, I didn't mean to point out autowiring as an example of how T5
@Inject is bad or anything, just more around the point of having to
specify the service id. If I could have @Inject without having to give
it an ID that would be much preferrable. (and would avoid all of my
little /* injected */ comments above them as they'd be self
documenting )
On 3/9/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> Well, @Inject in T5 is very smart; its a chain-of-command (and
> extensible) that can try a bunch of different things; with an Asset
> field, the annotation value is the path to the asset, with a Block
> field, the annotation value is the id of the block, with a bunch of
> pre-determined types, it just knows what to do, and for everything
> else, it looks for a unique service with the matching service
> interface.
>
> On 3/9/07, Jesse Kuhnert <jk...@gmail.com> wrote:
> > +1
> >
> > It's definitely worth exploring...I guess you are starting to have
> > enough code sitting around now to test the theory against. (spring /
> > hibernate)
> >
> > I do have to admit that I almost never use @InjectObject now with the
> > autowire stuff built in from James. Not exactly the same thing totally
> > but it is similar enough to draw some sort of opinion from.
> >
> > On 3/9/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> > > I've been giving some thought towards simplifying Tapestry 5 IOC.
> > >
> > > I'm beginning to question the value of having a segmented namespace.
> > >
> > > Let me clarify; I think there are situations, if and when you have
> > > large (dozens) of modules, where a segmented namespace is valuable.
> > > However, in the typical case (a normal Tapestry application with a
> > > component library or two) it is unlikely that naming will get that
> > > complicated, and having simple naming is easier to understand.
> > >
> > > This would eliminate the @Id annotation on module builders (they
> > > wouldn't need IDs at all). I believe the @Contribute annotation would
> > > also go (you would always be able to identify the service to
> > > contribute to directly from the method name). There's a lot of other
> > > logic, related to things like ordering, decorating, and service
> > > matching (GlobMatcher) as well that would simplify.
> > >
> > > --
> > > 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
> > Tapestry/Dojo team member/developer
> >
> > Open source based consulting work centered around
> > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
> >
> > ---------------------------------------------------------------------
> > 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
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Simplify Tapestry IoC?
Posted by Howard Lewis Ship <hl...@gmail.com>.
Well, @Inject in T5 is very smart; its a chain-of-command (and
extensible) that can try a bunch of different things; with an Asset
field, the annotation value is the path to the asset, with a Block
field, the annotation value is the id of the block, with a bunch of
pre-determined types, it just knows what to do, and for everything
else, it looks for a unique service with the matching service
interface.
On 3/9/07, Jesse Kuhnert <jk...@gmail.com> wrote:
> +1
>
> It's definitely worth exploring...I guess you are starting to have
> enough code sitting around now to test the theory against. (spring /
> hibernate)
>
> I do have to admit that I almost never use @InjectObject now with the
> autowire stuff built in from James. Not exactly the same thing totally
> but it is similar enough to draw some sort of opinion from.
>
> On 3/9/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> > I've been giving some thought towards simplifying Tapestry 5 IOC.
> >
> > I'm beginning to question the value of having a segmented namespace.
> >
> > Let me clarify; I think there are situations, if and when you have
> > large (dozens) of modules, where a segmented namespace is valuable.
> > However, in the typical case (a normal Tapestry application with a
> > component library or two) it is unlikely that naming will get that
> > complicated, and having simple naming is easier to understand.
> >
> > This would eliminate the @Id annotation on module builders (they
> > wouldn't need IDs at all). I believe the @Contribute annotation would
> > also go (you would always be able to identify the service to
> > contribute to directly from the method name). There's a lot of other
> > logic, related to things like ordering, decorating, and service
> > matching (GlobMatcher) as well that would simplify.
> >
> > --
> > 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
> Tapestry/Dojo team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>
> ---------------------------------------------------------------------
> 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: Simplify Tapestry IoC?
Posted by Jesse Kuhnert <jk...@gmail.com>.
+1
It's definitely worth exploring...I guess you are starting to have
enough code sitting around now to test the theory against. (spring /
hibernate)
I do have to admit that I almost never use @InjectObject now with the
autowire stuff built in from James. Not exactly the same thing totally
but it is similar enough to draw some sort of opinion from.
On 3/9/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> I've been giving some thought towards simplifying Tapestry 5 IOC.
>
> I'm beginning to question the value of having a segmented namespace.
>
> Let me clarify; I think there are situations, if and when you have
> large (dozens) of modules, where a segmented namespace is valuable.
> However, in the typical case (a normal Tapestry application with a
> component library or two) it is unlikely that naming will get that
> complicated, and having simple naming is easier to understand.
>
> This would eliminate the @Id annotation on module builders (they
> wouldn't need IDs at all). I believe the @Contribute annotation would
> also go (you would always be able to identify the service to
> contribute to directly from the method name). There's a lot of other
> logic, related to things like ordering, decorating, and service
> matching (GlobMatcher) as well that would simplify.
>
> --
> 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
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Simplify Tapestry IoC?
Posted by Jonas Maurus <jo...@gmail.com>.
Hey,
how would one go about creating a pluggable library for tapestry-ioc
without namespaces? In a typical Tapestry 4 application we have about
20 HiveMind modules. So I always found that HiveMind's
namespace-support was a huge advantage and necessity if compared
against Spring for providing and packaging libraries and modules,
while Spring is simpler to use if you just want to configure your
application.
As Tapestry is a framework, I'd like to see strong namespace-support
and enforcement so that modules can be distributed and plugged-in at
will.
I also might have completely misunderstood what you're trying to do here :-).
best regards,
Jonas Maurus
On 3/9/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> I've been giving some thought towards simplifying Tapestry 5 IOC.
>
> I'm beginning to question the value of having a segmented namespace.
>
> Let me clarify; I think there are situations, if and when you have
> large (dozens) of modules, where a segmented namespace is valuable.
> However, in the typical case (a normal Tapestry application with a
> component library or two) it is unlikely that naming will get that
> complicated, and having simple naming is easier to understand.
>
> This would eliminate the @Id annotation on module builders (they
> wouldn't need IDs at all). I believe the @Contribute annotation would
> also go (you would always be able to identify the service to
> contribute to directly from the method name). There's a lot of other
> logic, related to things like ordering, decorating, and service
> matching (GlobMatcher) as well that would simplify.
>
> --
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Simplify Tapestry IoC?
Posted by Massimo Lusetti <ml...@gmail.com>.
On 3/9/07, Howard Lewis Ship <hl...@gmail.com> wrote:
> I've been giving some thought towards simplifying Tapestry 5 IOC.
>
> I'm beginning to question the value of having a segmented namespace.
>
> Let me clarify; I think there are situations, if and when you have
> large (dozens) of modules, where a segmented namespace is valuable.
> However, in the typical case (a normal Tapestry application with a
> component library or two) it is unlikely that naming will get that
> complicated, and having simple naming is easier to understand.
My prototype for start to test/work with/learn T5 is an application
with 8 modules (maven term) of which 2 are independent web
applications.
I agree that probably it's not the better project for a prototype but
it's was i got and i trust T5 enough.
Said that i must admit after looking at the code, i wouldn't have had
the need for a namespace (till now). Anyway having it give me a good
comfort feeling and i don't mind having to type some more (small)
amount of code.
On of the libraries is also an hivemind one used through the bridge.
> This would eliminate the @Id annotation on module builders (they
> wouldn't need IDs at all). I believe the @Contribute annotation would
> also go (you would always be able to identify the service to
> contribute to directly from the method name). There's a lot of other
> logic, related to things like ordering, decorating, and service
> matching (GlobMatcher) as well that would simplify.
Contrarily i can understand this statement in terms of code clarity
which amost always turns in code with less bugs.
IMHO If we can say that T5 IoC future will still live within T5 web
framework your doubt are reasonable.
As always is up to you :) my only intention was to share an experience.
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org