You don't have to use it if you don't want to. I think the only negative here is the status quo. It's indeed a powerful negative, but... perhaps status quo isn't always a good thing.
I can see this being a boon for new tapestry developers. On Aug 24, 2011, at 3:26 PM, Igor Drobiazko wrote: > -1 > > Such a TapestryCoreServices goes against the fundamental ideas in Tapestry. > The framework is assembled from a lot of small pieces. You inject only what > you need and when you need. > > Did you know there is a page listing all the available services? > > http://tapestry.apache.org/service-status.html > > I strongly believe that TapestryCoreServices would not make your life > easier. Just imagine how many methods you would see in the autocompletion > box. I think more than 100. You will be lost. I remember the nightmare > writing Java swing code where every class inherits plenty of methods from > the super-classes. > > > On Wed, Aug 24, 2011 at 3:25 PM, Barry Books <[email protected]> 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > -- > Best regards, > > Igor Drobiazko > http://tapestry5.de --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
