Sure... in fact, it would be a fairly simple matter to create such a service and interface. Define your interface with whatever methods you want, then your implementation class injects the registry and gets the objects from the registry, or else injects the objects directly and returns them.
I'm not too keen on such a service in tapestry-core, but I understand your pain. There are a LOT of public services in Tapestry. Most of what you might want/need lives in org.apache.tapestry5.services. Some of it is in org.apache.tapestry5.ioc.services. You can use the javadoc to get at the list and function, but what I would love to see in our documentation is a "reverse lookup". A page that contains a list of (common) tasks and the service you would normally inject to accomplish the task, with a link to the service documentation. Something like: Task | Service Create a link to a page programmatically | PageRenderLinkSource Then any time someone found the answer "which service?" after a lengthy search, they could update the page (or ask that the page be updated). I think that would go a long way toward easing the initial learning curve! Robert On Aug 24, 2011, at 8/241:25 PM , Josh Canfield wrote: > Hi! > > I appreciate the effort required to get to know Tapestry. It's true > that being on the project for a long time can make it hard to see the > pain of the learning curve. > > Having a single point of entry for every object you might want to use > seems a little out there though. If you like this design you could > definitely create a service that injects all the thing you think are > core and then just inject that service. > > Josh > > On Wed, Aug 24, 2011 at 11:09 AM, Lenny Primak <lpri...@hope.nyc.ny.us> wrote: >> For example: >> core.getServiceFiter().contribute(myTimingFilter) >> core.getComponentResources().xxx(); >> core.getApplicationDefaults.set(); >> core.getJavaScriptSupport().importLibrary(); >> core.getFormSupport().xxx(); >> >> Basically, an interface that makes up 'core' services. >> Obviously, not complete but I think the you can get the idea here. >> >> Basically, a simple, one entry-point into the guts of tapestry via an API >> that's well defined >> rather than having to hunt for cookbooks/javadocs/example code, etc. >> >> >> On Aug 24, 2011, at 2:01 PM, Thiago H. de Paula Figueiredo wrote: >> >>> On Wed, 24 Aug 2011 14:49:36 -0300, Lenny Primak <lpri...@hope.nyc.ny.us> >>> wrote: >>> >>>> I think the key here at least for me is that there is one entry point for >>>> most common things. >>> >>> Then there's a problem: defining what is the most common things. >>> >>>> @Inject is nice but tapestry also has @Contribute and other inject >>>> variants. >>> >>> @Contribute is not used for injection at all. There's @Inject (used in at >>> least 99% of the time) and @InjectService (very seldomly used). >>> @InjectComponent, @InjectContainer are not related to dependency injection >>> at all. >>> >>>> I for one am having to constantly field questions on how do I do this and >>>> it's usually a question of doing an inject. The API will prevent those >>>> questions from happening in the first place. >>> >>> How would this API look like? What API you would use as inspiration? There >>> isn't a single definition of API nor just one way of architecting one. >>> >>> -- >>> Thiago H. de Paula Figueiredo >>> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, >>> and instructor >>> Owner, Ars Machina Tecnologia da Informação Ltda. >>> http://www.arsmachina.com.br >>> >>> --------------------------------------------------------------------- >>> 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 >> >> > > --------------------------------------------------------------------- > 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
