Quantcast

Parameterized service injection

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Parameterized service injection

Andrus Adamchik-2
From what I gather Tapestry 5.4 still does not support parameterized service injection? 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Parameterized service injection

Thiago H de Paula Figueiredo
Hi!

On Tue, Dec 13, 2016 at 5:31 AM, Andrus Adamchik <[hidden email]>
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Thiago
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Parameterized service injection

Lance Java
In reply to this post by Andrus Adamchik-2
You should be able to use @InjectService assuming each has a unique id.

  @InjectService("s1")
  private MyService<MyType1> s1;

  @InjectService("s2")
  private MyService<MyType2> s2;



On 13 Dec 2016 7:31 a.m., "Andrus Adamchik" <[hidden email]> wrote:

> From what I gather Tapestry 5.4 still does not support parameterized
> service injection? 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Parameterized service injection

Andrus Adamchik-2
Ah, good point. This might work. Let me see if I can properly bridge / generate service IDs from Guice to Tapestry.

Thanks,
Andrus

> On Dec 15, 2016, at 8:04 PM, Lance Java <[hidden email]> wrote:
>
> You should be able to use @InjectService assuming each has a unique id.
>
>  @InjectService("s1")
>  private MyService<MyType1> s1;
>
>  @InjectService("s2")
>  private MyService<MyType2> s2;
>
>
>
> On 13 Dec 2016 7:31 a.m., "Andrus Adamchik" <[hidden email]> wrote:
>
>> From what I gather Tapestry 5.4 still does not support parameterized
>> service injection? 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Parameterized service injection

Andrus Adamchik-2
In reply to this post by Thiago H de Paula Figueiredo
> 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 <[hidden email]> wrote:
>
> Hi!
>
> On Tue, Dec 13, 2016 at 5:31 AM, Andrus Adamchik <[hidden email]>
> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> --
> Thiago


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Parameterized service injection

Thiago H de Paula Figueiredo
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 <[hidden email]>
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 <
> [hidden email]> wrote:
> >
> > Hi!
> >
> > On Tue, Dec 13, 2016 at 5:31 AM, Andrus Adamchik <[hidden email]
> >
> > 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: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >
> >
> > --
> > Thiago
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Thiago
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Parameterized service injection

Andrus Adamchik-2
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 <[hidden email]> 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 <[hidden email]>
> 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 <
>> [hidden email]> wrote:
>>>
>>> Hi!
>>>
>>> On Tue, Dec 13, 2016 at 5:31 AM, Andrus Adamchik <[hidden email]
>>>
>>> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>>
>>> --
>>> Thiago
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> --
> Thiago


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...