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. > > > > -- > > 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
