You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tapestry.apache.org by "Igor Drobiazko (JIRA)" <ji...@apache.org> on 2009/01/13 21:31:01 UTC
[jira] Assigned: (TAP5-69) Allow service configurators to be
arbitrary named and determine sevice by the configuration parameter
[ 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Assigned: (TAP5-69) Allow service configurators to be arbitrary named and determine sevice by the configuration parameter
Posted by Yunhua Sang <yu...@gmail.com>.
Is it possible that @Contribute works with @Marker to make
contribution to a specified service in multiple implementation of one
interface?
e.g.
@Marker(Service1Marker.class)
Service buildService1() {};
@Marker(Service2Marker.class)
Service buildService2() {};
@Contribute(Service.class)
@Marker(Service1Marker.class)
public static void foo1(MappedConfiguration<String,String> configuration)
@Contribute(Service.class)
@Marker(Service2Marker.class)
public static void foo2(MappedConfiguration<String,String> configuration)
Now I have to use
contributeService1(MappedConfiguration <String,String> configuration);
contributeService2(MappedConfiguration <String,String> configuration);
Which is not refactoring safe.
Thanks,
Yunhua
On Tue, Jan 13, 2009 at 4:38 PM, Fernando Padilla <fe...@alum.mit.edu> wrote:
> right, so the current extra precise method is still available right?
>
> but if you right a module that doesn't do precise contributions, then anyone
> importing that module will never be able to create a different service with
> the same type.. right?
>
> anyhow.. nice idea to clean up stuff, just realize that there is cost to
> having the code be too smart.. :)
>
> Igor Drobiazko wrote:
>>
>> 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
>> <fe...@alum.mit.edu>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 <fe...@alum.mit.edu>
>>>> 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: dev-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Assigned: (TAP5-69) Allow service configurators to be
arbitrary named and determine sevice by the configuration parameter
Posted by Fernando Padilla <fe...@alum.mit.edu>.
right, so the current extra precise method is still available right?
but if you right a module that doesn't do precise contributions, then
anyone importing that module will never be able to create a different
service with the same type.. right?
anyhow.. nice idea to clean up stuff, just realize that there is cost to
having the code be too smart.. :)
Igor Drobiazko wrote:
> 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 <fe...@alum.mit.edu>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 <fe...@alum.mit.edu>
>>> 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: dev-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>>
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Assigned: (TAP5-69) Allow service configurators to be arbitrary named and determine sevice by the configuration parameter
Posted by Igor Drobiazko <ig...@gmail.com>.
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 <fe...@alum.mit.edu>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 <fe...@alum.mit.edu>
>> 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: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko
Re: [jira] Assigned: (TAP5-69) Allow service configurators to be
arbitrary named and determine sevice by the configuration parameter
Posted by Fernando Padilla <fe...@alum.mit.edu>.
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 <fe...@alum.mit.edu> 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: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Assigned: (TAP5-69) Allow service configurators to be arbitrary named and determine sevice by the configuration parameter
Posted by Igor Drobiazko <ig...@gmail.com>.
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 <fe...@alum.mit.edu> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko
Re: [jira] Assigned: (TAP5-69) Allow service configurators to be
arbitrary named and determine sevice by the configuration parameter
Posted by Fernando Padilla <fe...@alum.mit.edu>.
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org