You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2014/06/16 03:20:02 UTC

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

    [ https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14032073#comment-14032073 ] 

ASF subversion and git services commented on TAP5-1611:
-------------------------------------------------------

Commit e6a83e031ad65eac99614f108392d06a8ff6c8f9 in tapestry-5's branch refs/heads/master from [~thiagohp]
[ https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;h=e6a83e0 ]

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


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