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
