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