Thanks very much for the help, guys! I successfully employed the approach
detailed by Thiago, with a little extra finessing from the man himself, and
it's working exactly the way I want.
John
On Sat, Dec 7, 2013 at 8:22 AM, Thiago H de Paula Figueiredo <
thiag...@gmail.com> wrote:
> On Fri, 06 Dec 2013 22:57:14 -0200, John Prestel <
> jpres...@safaribooksonline.com> wrote:
>
> I'm building a service MasterFooProvider that takes contributions of type
>> FooProvider. I'd really love for one my FooProvider implementations,
>> ConfigurableFooProvider, to be able to take contributions of its own (of
>> type String), so its behavior can be customized.
>>
>
> Hello, John!
>
> That's what I'd do, not tested:
>
> * ConfigurableFooProvider is declared as a service.
> * Contribute ConfigurableFooProvider to MasterFooProvider normally, but
> not using addInstance(), because addInstance() doesn't make
> ConfigurableFooProvider a service, so it cannot receive contributions.
>
> public static void bind(ServiceBinder binder) {
> binder.bind(ConfigurableFooProvider.class)
> .withMarker(Primary.class);
> binder.bind(SubclassConfigurableFooProvider.class).withId("
> SubclassConfigurableFooProvider");
> }
>
> public static void contributeMasterFooProvider(
> OrderedConfiguration<FooProvider> config,
> @Primary ConfigurableFooProvider configurableFooProvider,
> @InjectService("SubclassConfigurableFooProvider")
> SubclassConfigurableFooProvider) {
> config.add("ConfigurableFoo", configurableFooProvider);
> }
>
> public static void
> contributeConfigurableFooProvider(OrderedConfiguration<String>
> config) {
> ...
>
> }
>
> To make matters more complicated, I have the need to sub-class
>> ConfigurableFooProvider, and I don't want the derived classes to share
>> configuration. In other words, I want to be able to configure/contribute
>> to each sub-class separately.
>>
>
> That's not a problem at all. Just make sure you're contributing to the
> right service by the right method name
>
> public static void
> contributeConfigurableFooProvider(OrderedConfiguration<String>
> config) {
>
> }
>
> public static void
> contributeSubclassConfigurableFooProvider(OrderedConfiguration<String>
> config) {
>
> }
>
> To avoid ambiguity, which Tapestry-IoC considers as a showstopper, use a
> marker annotation or a service id when declaring and injecting
> ConfigurableFooProvider and declare the subclass as another service. My
> example above uses the Tapestry-provided @Primary annotation for the
> superclass and id for the subclass as examples.
>
> --
> Thiago H. de Paula Figueiredo
> Tapestry, Java and Hibernate consultant and developer
> http://machina.com.br
> Help me spend a whole month working on Tapestry bug fixes and
> improvements: http://igg.me/at/t5month
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
--
*John Prestel*
Software Engineer
Safari Books Online, LLC | http://www.safaribooksonline.com
33 Farnsworth Street
Boston, MA 02210
617.235.5806
*Please update your address book with my new address*:
jpres...@safaribooksonline.com
