> 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
