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

["Lance (JIRA)" <ji...@apache.org>]

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

Lance edited comment on TAP5-1611 at 10/15/13 8:02 AM:
-------------------------------------------------------

I'm not sure it's legal to be referencing component classes 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:
{code}
public static void contributeComponentOverrides(MappedConfiguration<String, String> config) {
    config.add("grid", "com.basepackage.components.MyGrid");
}
{code}

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


was (Author: uklance):
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:
{code}
public static void contributeComponentOverrides(MappedConfiguration<String, String> config) {
    config.add("grid", "com.basepackage.components.MyGrid");
}
{code}

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
(v6.1#6144)