tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Barry Books (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
Date Thu, 10 Oct 2013 12:39:43 GMT

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

Barry Books commented on TAP5-1611:

This would be a really useful feature. Could it work for mixins also? I think there could
be many uses for this. For example I noticed 5.4 uses a mixin to add the bootstrap markup
the EditBlocks. It would be great if I could override that mixin and replace it with one that
supported a different framework.

> 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-ioc
>    Affects Versions: 5.3
>            Reporter: Jens Breitenstein
>            Assignee: Thiago H. de Paula Figueiredo
>            Priority: Minor
>              Labels: IOC, component
> 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

View raw message