hOn 3/10/07, Ben Sommerville <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
