[jira] [Resolved] (TAP5-1611) out-of-the-box way in Tapestry for replacing components

["Thiago H. de Paula Figueiredo (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thiago H. de Paula Figueiredo resolved TAP5-1611.
-------------------------------------------------

       Resolution: Fixed
    Fix Version/s: 5.4

A new service, ComponentReplacer, was created. It receives a mapped configuration of Class, Class (page, component or mixin class to be replaced, page, component or mixin class to be used as replament). The service shouldn't be used directly. Component, page and mixin replacement works just by contributing to ComponentReplacer. No checks were added about replaced class and its replacement.

> out-of-the-box way in Tapestry for replacing components
> -------------------------------------------------------
>
>                 Key: TAP5-1611
>                 URL: https://issues.apache.org/jira/browse/TAP5-1611
>             Project: Tapestry 5
>          Issue Type: New Feature
>          Components: tapestry-core
>    Affects Versions: 5.3
>            Reporter: Jens Breitenstein
>            Assignee: Thiago H. de Paula Figueiredo
>            Priority: Minor
>              Labels: component, month-of-tapestry
>             Fix For: 5.4
>
>
> 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. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)