Yep, doing something like that. Here is the package in the code that implements the bridge:
https://github.com/bootique/bootique-tapestry/tree/master/src/main/java/io/bootique/tapestry/di Comments, suggestions and pull requests are welcome. Andrus > On Dec 19, 2016, at 8:19 PM, Thiago H. de Paula Figueiredo > <thiag...@gmail.com> wrote: > > Hi! > > Maybe you could try contributing an ObjectProvider to MasterObjectProvider > if you haven't done so yet (I'm sorry, I'm curious to see your Guice to > Tapestry-IoC implementation, but I haven't had the time to do it yet). > > On Fri, Dec 16, 2016 at 5:12 AM, Andrus Adamchik <and...@objectstyle.com> > wrote: > >>> I haven't found yet a situation in which I wanted something >>> like that. >>> I've see people creating a MyServiceSource service, for example, >>> which then provides the type-specific services, though. I'm more of a fan >>> of having specific subclasses or implementations for each type in most >>> cases. :) >> >> Designing around functional concepts leads to more shallow parameterized >> class hierarchies. So yeah, subclassing could have been a solution, just >> not an ideal one. My scenario was an object factory service to be used >> inside page 'onActivate' to decode EventContext following some internal >> "protocol" (not a replacement of ValueEncoder, but rather something that >> works on top of encoders). E.g.: >> >> class PersonEditorPage { >> >> @Inject >> Factory<Person> factory; >> } >> >> >> class DepartmentEditorPage { >> >> @Inject >> Factory<Department> factory; >> } >> >> Essentially there's a single factory class encapsulating parsing >> EventContext sequence. Entity-specific business logic is encapsulated as >> lambdas inside that class. >> >> Ended up creating factories on every page from scratch inside >> 'pageLoaded'. Not ideal, as this requires injection of extra services that >> the page itself doesn't care about. Still with a common page superclass and >> redefining necessary lambdas on each page, the end result doesn't look too >> bad. >> >> Will need to explore service IDs at some point as mentioned by Lance. >> >> Thanks, >> Andrus >> >> >> >> >>> On Dec 14, 2016, at 11:06 PM, Thiago H. de Paula Figueiredo < >> thiag...@gmail.com> wrote: >>> >>> Hi! >>> >>> On Tue, Dec 13, 2016 at 5:31 AM, Andrus Adamchik <and...@objectstyle.com >>> >>> wrote: >>> >>>> From what I gather Tapestry 5.4 still does not support parameterized >>>> service injection? >>> >>> >>> It does not. I haven't found yet a situation in which I wanted something >>> like that. I've see people creating a MyServiceSource service, for >> example, >>> which then provides the type-specific services, though. I'm more of a fan >>> of having specific subclasses or implementations for each type in most >>> cases. :) >>> >>> On the other hand, you could use marker annotations to avoid the >>> MyServiceSouce service above, so maybe that's a path you can use as the >>> source of inspiration in case you want to add parameterized service >>> injection to Tapestry-IoC. We're open for contributions. :) >>> >>> >>>> E.g. in the following example both s1 and s2 will map to the same DI key >>>> of the bare class: >>>> >>>> @Inject >>>> private MyService<MyType1> s1; >>>> >>>> @Inject >>>> private MyService<MyType2> s2; >>>> >>>> I am running Tapestry on a Bootique.io stack with underlying injection >>>> bridged to Google Guice, that supports the above style. So I am a bit >>>> crippled by this limitation. I may (or may not :)) have time to develop >> and >>>> contribute this functionality to Tapestry, but before I start digging >> any >>>> deeper, wanted to check whether this is already in the works (or >> perhaps I >>>> overlooked something obvious, and I simply need to revise my Guice to >>>> tapestry bridge)? >>>> >>>> Thanks for any insight. >>>> >>>> Andrus >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>> For additional commands, e-mail: users-h...@tapestry.apache.org >>>> >>>> >>> >>> >>> -- >>> Thiago >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> > > > -- > Thiago --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
