tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
Date Tue, 15 Oct 2013 08:01:50 GMT

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

Lance commented on TAP5-1611:

I'm not sure it's legal to be referencing component class files in your AppModule since component
classes are loaded by the component classloader. It's probably better to reference class names
instead to avoid cluttering permgen unnecessarily. I think the config would be similar to:
public static void contributeComponentOverrides(MappedConfiguration<String, String>
config) {
    config.add("grid", "com.basepackage.components.MyGrid");

I'm also wondering if the override actually needs to extend the component it is overriding.
It might be sufficient for it to be compatible (same properties / interfaces).

> 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