Providing a type of the service makes you to avoid DRY. You don't have to repeat the service id again. So, in case of several implementations of a service interface you should use the naming convention and provide extra contribute method for each implementation.
On Tue, Jan 13, 2009 at 10:04 PM, Fernando Padilla <[email protected]>wrote: > So the Contribute would support either a class or an arbitrary service > name? (for when there are two services who implement the same interface, > etc) > > > Igor Drobiazko wrote: > >> The value attribute of the annotation is used to determine the service to >> contribute into. The type of the configuration does not provide enough >> information for it. See an example below: >> >> @Contribute(Runnable.class) >> public static void bar(MappedConfiguration<String,String> >> configuration) >> { >> >> } >> >> @Contribute(SomeAnotherService.class) >> public static void foo(MappedConfiguration<String,String> >> configuration) >> { >> >> } >> >> On Tue, Jan 13, 2009 at 9:53 PM, Fernando Padilla <[email protected]> >> wrote: >> >> but what if I want to have two different services that are configured >>> using >>> the same typed configuration?? >>> >>> the name and the type of the configuration are both important. >>> >>> >>> Igor Drobiazko (JIRA) wrote: >>> >>> [ >>>> >>>> https://issues.apache.org/jira/browse/TAP5-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >>>> ] >>>> >>>> Igor Drobiazko reassigned TAP5-69: >>>> ---------------------------------- >>>> >>>> Assignee: Igor Drobiazko >>>> >>>> Allow service configurators to be arbitrary named and determine sevice >>>> by >>>> >>>>> the configuration parameter >>>>> >>>>> >>>>> ----------------------------------------------------------------------------------------------------- >>>>> >>>>> Key: TAP5-69 >>>>> URL: https://issues.apache.org/jira/browse/TAP5-69 >>>>> Project: Tapestry 5 >>>>> Issue Type: Improvement >>>>> Affects Versions: 5.0.15 >>>>> Reporter: Kalin Krustev >>>>> Assignee: Igor Drobiazko >>>>> >>>>> Tapestry used to require this naming convention for configuring >>>>> services: >>>>> public static Foo buildFoo(...) {...} >>>>> public static void contrubuteFoo(...) {...} >>>>> Then it allowed the first convention to be simplified as: >>>>> public static Foo build(...) {...} >>>>> It would be nice for the "contribute..." methods to allow also simpler >>>>> naming and use the type of the "configuration" parameter to determine >>>>> the >>>>> configured service, which will also have the same type of parameter. >>>>> For example: >>>>> in Tapestry 5.0.5 TapestryModule.java: >>>>> public ServletApplicationInitializer build(..., >>>>> List<ServletApplicationInitializerFilter> configuration, ... ) >>>>> in my AppModule.java Tapestry 5.0.5 requires this naming: >>>>> public void >>>>> >>>>> contributeServletApplicationInitializer(OrderedConfiguration<ServletApplicationInitializerFilter> >>>>> configuration) >>>>> Perhaps it could be simplified as: >>>>> public void >>>>> contribute(OrderedConfiguration<ServletApplicationInitializerFilter> >>>>> configuration) >>>>> If it will not be simplified, it would be nice to make the >>>>> documentation >>>>> about Tapestry IoC Configurations more clear that >>>>> the naming of the contribute methods is important, not the type of >>>>> configuration parameter. >>>>> >>>>> >>>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Best regards, Igor Drobiazko
