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:[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > Yep, that's the inject ... it should Just Work (tm). > > > > > > On 3/9/07, Jesse Kuhnert <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
