Tapestry 5
  1. Tapestry 5
  2. TAP5-69

Add annotation, @Contribute, to allow service contributor methods to be arbitrary named

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 5.0.15
    • Fix Version/s: 5.2.0
    • Component/s: None
    • Labels:
      None

      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.

        Issue Links

          Activity

          Kalin Krustev created issue -
          Kalin Krustev made changes -
          Field Original Value New Value
          Link This issue is a clone of TAPESTRY-1341 [ TAPESTRY-1341 ]
          Kalin Krustev made changes -
          Affects Version/s 5.0 [ 12312018 ]
          Fix Version/s 5.0.3 [ 12312338 ]
          Affects Version/s 5.0.5 [ 12312477 ]
          Description 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.
          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)

          Kalin Krustev made changes -
          Link This issue relates to TAPESTRY-1341 [ TAPESTRY-1341 ]
          Kalin Krustev made changes -
          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)

          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.
          Hide
          Howard M. Lewis Ship added a comment -

          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).

          Show
          Howard M. Lewis Ship added a comment - 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).
          Hide
          Kalin Krustev added a comment -

          This seems good approach to me, but can you explain what is the idea of this further qualification ?

          Show
          Kalin Krustev added a comment - This seems good approach to me, but can you explain what is the idea of this further qualification ?
          Howard M. Lewis Ship made changes -
          Fix Version/s 5.1 [ 12312964 ]
          Howard M. Lewis Ship made changes -
          Assignee Howard M. Lewis Ship [ hlship ]
          Howard M. Lewis Ship made changes -
          Project Tapestry [ 10573 ] Tapestry 5 [ 12310833 ]
          Affects Version/s 5.0.5 [ 12312477 ]
          Key TAPESTRY-1679 TAP5-69
          Fix Version/s 5.1 [ 12312964 ]
          Issue Type New Feature [ 2 ] Bug [ 1 ]
          Component/s tapestry-ioc [ 12311284 ]
          Howard M. Lewis Ship made changes -
          Affects Version/s 5.0.15 [ 12313429 ]
          Howard M. Lewis Ship made changes -
          Issue Type Bug [ 1 ] Improvement [ 4 ]
          Igor Drobiazko made changes -
          Assignee Igor Drobiazko [ igor.drobiazko ]
          Igor Drobiazko made changes -
          Summary Allow service configurators to be arbitrary named and determine sevice by the configuration parameter Add annotation, @Contribute, to allow service contributor methods to be arbitrary named
          Hide
          Howard M. Lewis Ship added a comment -

          The goal for this is that, should the service id change, none of the contribution methods to that service be affected.

          This is reflective of the overall direction of the framework, where increasingly, services are identified by the combination of type plus one or more marker annotations, rather than by service id.

          However, currently (5.0) contribution methods are linked to services by the id, which is incorporated into the method name.

          The goal here is to use @Contribute (to specify the service interface) plus marker annotations and no longer care what the name of the contribute method is.

          Show
          Howard M. Lewis Ship added a comment - The goal for this is that, should the service id change, none of the contribution methods to that service be affected. This is reflective of the overall direction of the framework, where increasingly, services are identified by the combination of type plus one or more marker annotations, rather than by service id. However, currently (5.0) contribution methods are linked to services by the id, which is incorporated into the method name. The goal here is to use @Contribute (to specify the service interface) plus marker annotations and no longer care what the name of the contribute method is.
          Igor Drobiazko made changes -
          Resolution Fixed [ 1 ]
          Fix Version/s 5.1.0.0 [ 12313428 ]
          Status Open [ 1 ] Closed [ 6 ]
          Hide
          Igor Drobiazko added a comment -

          Reopened because fix is invalid

          Show
          Igor Drobiazko added a comment - Reopened because fix is invalid
          Igor Drobiazko made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          Howard M. Lewis Ship made changes -
          Fix Version/s 5.1 [ 12313499 ]
          Fix Version/s 5.1.0.0 [ 12313428 ]
          Robert Zeigler made changes -
          Fix Version/s 5.1 [ 12313499 ]
          Igor Drobiazko made changes -
          Status Reopened [ 4 ] In Progress [ 3 ]
          Igor Drobiazko made changes -
          Status In Progress [ 3 ] Closed [ 6 ]
          Fix Version/s 5.2.0 [ 12314122 ]
          Resolution Fixed [ 1 ]

            People

            • Assignee:
              Igor Drobiazko
              Reporter:
              Kalin Krustev
            • Votes:
              2 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development