[TAP5-1611] out-of-the-box way in Tapestry for replacing components

• Type: New Feature
• Status: Resolved
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 5.3
• Fix Version/s: 5.4
• Component/s: tapestry-core
• Labels: component month-of-tapestry
• Assignee: Thiago Henrique De Paula Figueiredo
• Reporter: Jens Breitenstein
• Created: 15/Aug/11 19:17
• Updated: 26/Jun/14 09:32
• Resolved: 16/Jun/14 01:22

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.