You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Kalin Krustev (JIRA)" <de...@tapestry.apache.org> on 2007/07/30 07:56:52 UTC
[jira] Created: (TAPESTRY-1679) Allow service configurators to be
arbitrary named and determine sevice by the configuration parameter
Allow service configurators to be arbitrary named and determine sevice by the configuration parameter
-----------------------------------------------------------------------------------------------------
Key: TAPESTRY-1679
URL: https://issues.apache.org/jira/browse/TAPESTRY-1679
Project: Tapestry
Issue Type: New Feature
Components: tapestry-ioc
Affects Versions: 5.0
Reporter: Kalin Krustev
Assignee: Howard M. Lewis Ship
Fix For: 5.0.3
Threre's a strong pattern for service builders of the form:
Foo buildFoo(...) { ... }
In fact, virtually all service builders are of this form.
Seems like a Dont Repeat Yourself violation.
Foo build(...) {...}
seems completely reasonable; determine the service id from the service interface name (the unqualified part).
Obviously, the current behavior would be left for the reasonable cases where you need to provide a specific service id.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAPESTRY-1679) Allow service configurators to be
arbitrary named and determine sevice by the configuration parameter
Posted by "Howard M. Lewis Ship (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556000#action_12556000 ]
Howard M. Lewis Ship commented on TAPESTRY-1679:
------------------------------------------------
Been thinking that we could use something like:
@ServiceMarker @Contribute(MyService.class) void arbitraryNamedMethod(...) { ... }
So, the @Contribute annotation marks the method as a contribution method. The value attribute is the type of service to contribute into. This may be further qualified by the additional annotation (@ServiceMarker, here).
> Allow service configurators to be arbitrary named and determine sevice by the configuration parameter
> -----------------------------------------------------------------------------------------------------
>
> Key: TAPESTRY-1679
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1679
> Project: Tapestry
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.0.5
> Reporter: Kalin Krustev
> Assignee: Howard M. Lewis Ship
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Updated: (TAPESTRY-1679) Allow service configurators to be
arbitrary named and determine sevice by the configuration parameter
Posted by "Kalin Krustev (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kalin Krustev updated TAPESTRY-1679:
------------------------------------
Description:
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.
was:
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)
> Allow service configurators to be arbitrary named and determine sevice by the configuration parameter
> -----------------------------------------------------------------------------------------------------
>
> Key: TAPESTRY-1679
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1679
> Project: Tapestry
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.0.5
> Reporter: Kalin Krustev
> Assignee: Howard M. Lewis Ship
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Updated: (TAP5-69) Allow service configurators to be
arbitrary named and determine sevice by the configuration parameter
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship updated TAP5-69:
-------------------------------------
Issue Type: Improvement (was: Bug)
> 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
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Updated: (TAPESTRY-1679) Allow service configurators to be
arbitrary named and determine sevice by the configuration parameter
Posted by "Howard M. Lewis Ship (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship updated TAPESTRY-1679:
-------------------------------------------
Fix Version/s: 5.1
> Allow service configurators to be arbitrary named and determine sevice by the configuration parameter
> -----------------------------------------------------------------------------------------------------
>
> Key: TAPESTRY-1679
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1679
> Project: Tapestry
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.0.5
> Reporter: Kalin Krustev
> Assignee: Howard M. Lewis Ship
> Fix For: 5.1
>
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Updated: (TAPESTRY-1679) Allow service configurators to be
arbitrary named and determine sevice by the configuration parameter
Posted by "Kalin Krustev (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kalin Krustev updated TAPESTRY-1679:
------------------------------------
Fix Version/s: (was: 5.0.3)
Description:
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)
was:
Threre's a strong pattern for service builders of the form:
Foo buildFoo(...) { ... }
In fact, virtually all service builders are of this form.
Seems like a Dont Repeat Yourself violation.
Foo build(...) {...}
seems completely reasonable; determine the service id from the service interface name (the unqualified part).
Obviously, the current behavior would be left for the reasonable cases where you need to provide a specific service id.
Affects Version/s: (was: 5.0)
5.0.5
> Allow service configurators to be arbitrary named and determine sevice by the configuration parameter
> -----------------------------------------------------------------------------------------------------
>
> Key: TAPESTRY-1679
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1679
> Project: Tapestry
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.0.5
> Reporter: Kalin Krustev
> Assignee: Howard M. Lewis Ship
>
> 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)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Updated: (TAPESTRY-1679) Allow service configurators to be
arbitrary named and determine sevice by the configuration parameter
Posted by "Howard M. Lewis Ship (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship updated TAPESTRY-1679:
-------------------------------------------
Assignee: (was: Howard M. Lewis Ship)
> Allow service configurators to be arbitrary named and determine sevice by the configuration parameter
> -----------------------------------------------------------------------------------------------------
>
> Key: TAPESTRY-1679
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1679
> Project: Tapestry
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.0.5
> Reporter: Kalin Krustev
> Fix For: 5.1
>
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAPESTRY-1679) Allow service configurators to be
arbitrary named and determine sevice by the configuration parameter
Posted by "Kalin Krustev (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556079#action_12556079 ]
Kalin Krustev commented on TAPESTRY-1679:
-----------------------------------------
This seems good approach to me, but can you explain what is the idea of this further qualification ?
> Allow service configurators to be arbitrary named and determine sevice by the configuration parameter
> -----------------------------------------------------------------------------------------------------
>
> Key: TAPESTRY-1679
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1679
> Project: Tapestry
> Issue Type: New Feature
> Components: tapestry-ioc
> Affects Versions: 5.0.5
> Reporter: Kalin Krustev
> Assignee: Howard M. Lewis Ship
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org