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