Re: Parameterized service injection
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 factory;
>> }
>>
>>
>> class DepartmentEditorPage {
>>
>> @Inject
>> Factory 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 s1;
>>>>
>>>> @Inject
>>>> private MyService 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
Re: Parameterized service injection
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 factory;
> }
>
>
> class DepartmentEditorPage {
>
> @Inject
> Factory 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 s1;
> >>
> >> @Inject
> >> private MyService 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
Re: Parameterized service injection
> 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 factory;
}
class DepartmentEditorPage {
@Inject
Factory 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 s1;
>>
>> @Inject
>> private MyService 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
Re: Parameterized service injection
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 <lance.j...@googlemail.com> wrote:
>
> You should be able to use @InjectService assuming each has a unique id.
>
> @InjectService("s1")
> private MyService s1;
>
> @InjectService("s2")
> private MyService s2;
>
>
>
> On 13 Dec 2016 7:31 a.m., "Andrus Adamchik" <and...@objectstyle.com> 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 s1;
>>
>> @Inject
>> private MyService 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
>>
>>
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Parameterized service injection
You should be able to use @InjectService assuming each has a unique id.
@InjectService("s1")
private MyService s1;
@InjectService("s2")
private MyService s2;
On 13 Dec 2016 7:31 a.m., "Andrus Adamchik" <and...@objectstyle.com> 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 s1;
>
> @Inject
> private MyService 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
>
>
Re: Parameterized service injection
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 s1; > > @Inject > private MyService 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
Parameterized service injection
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 s1; @Inject private MyService 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
