[ https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14032257#comment-14032257 ]
Lance commented on TAP5-1611: ----------------------------- Thanks v. much for the impl but I have a couple of issues. 1. I think ComponentReplacer should be called ComponentOverride to be consistend with [ServiceOverride|http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/ioc/services/ServiceOverride.html] 2. Tapestry has complex classloading for component classes and I don't feel that `java.lang.Class` instances for components are valud in an AppModule. I feel that it should be strings instead. eg {code} public static void contributeComponentClassResolver(Configuration<LibraryMapping> config, Logger log) { config.add(new LibraryMapping("lib1", "foo.bar.lib1")); config.add(new LibraryMapping("lib2", "foo.bar.lib2")); } public static void ContributeComponentOverride(MappedConfiguration<String,String> config) { config.add("lib1.someComponent", "lib2.someComponentOverride"); } {code} > 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)