I have been thinking about this as well. This is a general problem with dependency injection. When a.developer wants something, it's hard to search for it in the world of DI. it's much easier to have an API to do things. Right now there are hundreds of objects to inject, and each of them has many getter methods and indirections to get at the thing that a developer might want. Also there are hundreds of contribution and override points. Its next to impossible to find the right thing to do when coming from a new developer perspective. Even if you know what to inject or contribute, it's hard without the code examples. It's partly a documentation problem but I think it's really hard to fix just in the docs since the are so many permutations of what a developer might do.
Thus, I think an API is a great idea. On Aug 24, 2011, at 9:25 AM, Barry Books <trs...@gmail.com> wrote: > I just spent about 30 minutes looking for a way to get the > ServletContext. I knew it was available but I could not remember which > service provides it. So while I was searching I was thinking it might > be nice to have a set of Interfaces/Services that define all the > public services. For Tapestry core that might be TapestryCoreServices > and TapestryCoreRequestServices to differentiate between global > services and ones that are request specific. This would help with a > few things. One I could just say > > @Inject > private TapestryCoreServices coreServices; > > then just > coreServices.getApplicationGlobals().getServletContext() > > This would cut down on the number of fields I need to create just to > call a few methods. Secondly I think would make it more obvious which > services are public and which are internal. I realize the package does > that but who looks at the package name? Lastly I think it would be > easier for new comers to learn what services are available. The last > one is not a complaint about the documentation but more a comment > about how useful code completion can be. > > So in short the Interface would give you a starting point to all the > services available from a module. The naming convention could continue > such as TapestryIOCServices etc. > > Thanks > Barry > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
