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

          Hide
          Igor Drobiazko added a comment -

          Reopened because fix is invalid

          Show
          Igor Drobiazko added a comment - Reopened because fix is invalid
          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.
          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 ?
          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).

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development