Re: Contributing an object that itself can take contributions?
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(
OrderedConfigurationFooProvider config,
@Primary ConfigurableFooProvider configurableFooProvider,
@InjectService(SubclassConfigurableFooProvider)
SubclassConfigurableFooProvider) {
config.add(ConfigurableFoo, configurableFooProvider);
}
public static void
contributeConfigurableFooProvider(OrderedConfigurationString
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(OrderedConfigurationString
config) {
}
public static void
contributeSubclassConfigurableFooProvider(OrderedConfigurationString
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
Re: IndieGogo campaign: a month of Apache Tapestry 5
Congratulations, Thiago! On Mon, Dec 9, 2013 at 6:43 PM, Jens Breitenstein mailingl...@j-b-s.dewrote: done! Am 09.12.13 23:53, schrieb Chris Mylonas: $3880 / $4500 $620 to go On Tue, Dec 10, 2013 at 7:21 AM, Joachim Van der Auwera li...@progs.be wrote: Great initiative, twelve hours and 740$ to go. Let's make it happen! May I remind you that Thiago will not receive any money (donations are refunded) when the target is not met, so if you want Thiago to spend a month full-time on Tapestry, then now is the time to do your part and contribute to the campaign. Kind regards, Joachim On 12/09/2013 09:07 PM, Muhammad Gelbana wrote: I'm so happy you're approaching your goal ! Gonna see a more powerful Tapestry soon I hope :) *-* *Muhammad Gelbana* http://www.linkedin.com/in/mgelbana On Mon, Dec 9, 2013 at 7:47 PM, Thiago H de Paula Figueiredo thiag...@gmail.com wrote: Status update: With 14 hours until the deadline, we raised 3040 dollars out of 4500 goal. Thank you very much for everybody who contributed or helped spread the word. :) -- 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 - 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 -- *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
Contributing an object that itself can take contributions?
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.
My first stab at implementing this failed.
I made ConfigurableFooProvider a concrete class that implements FooProvider,
and I tried annotating it the class (not interface) with
@UsesConfiguration(String.class). Its constructor takes a ListStringparam.
In my AppModule, I have:
contributeMasterFooProvider() ( OrderedConfigurationFooProvider config) {
config.addInstance(ConfigurableFoo, ConfigurableFooProvider.class);
}
What wound up happening is that Tapestry fails to build MasterFooProvider
with an exception saying that a contribution of type
ConfigurableFooProvider is invalid, because MasterFooProvider expects
contributions of type String.
So I'm pretty sure one misstep I took was trying to make contributions to
an impl instead of an interface, but it's not clear to me if it would work.
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.
Is there a way to do what I'd like to do here, or do I need to change my
approach to making a configurable FooProvider?
John
