Uploaded image for project: 'Tapestry 5'
  1. Tapestry 5
  2. TAP5-1611

out-of-the-box way in Tapestry for replacing components

    Details

      Description

      It would be nice to allow global component replacement by a different component class (or derived version from the original) compared to the field type provided. So @InjectComponent would behave more or less like @Inject for services without the need of Interfaces.

      NOTE:

      current workaround is decorating ComponentInstantiatorSource

      As Thiago outlines my workaround is sub-optimal as it bases on internal classes which might subject to change without notice. He suggests to have an Service we can contribute our "overrides" to. Replaceing components would introduce a new level of flexibility to change implementations without touching tml's at all. Naturally ServiceBinder was not my suggested place for this new kind of "binding", seems to be a misunderstanding. From a functional point of view I was just thinking about something like...

      public static void bind(final ComponentBinder binder)

      { binder.bind(ComponentA,class, ComponentBderivedFromA.class); }

      ...this, as an example.

        Attachments

          Activity

            People

            • Assignee:
              thiagohp Thiago H. de Paula Figueiredo
              Reporter:
              jens breitenstein Jens Breitenstein
            • Votes:
              4 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: