[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14032257#comment-14032257
]
Lance edited comment on TAP5-1611 at 6/16/14 9:28 AM:
------------------------------------------------------
Thanks v. much for the impl but I have a couple of issues.
1. I think ComponentReplacer should be called ComponentOverride to be
consistent 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 valid in an AppModule (the
class can change in development mode and will not be equal over time). 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}
was (Author: uklance):
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 not valid in an AppModule
(the class can change in development mode and will not be equal). 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)
