[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14032513#comment-14032513
]
Thiago H. de Paula Figueiredo edited comment on TAP5-1611 at 6/16/14 3:04 PM:
------------------------------------------------------------------------------
Hi, Lance!
Thanks for reviewing my commit. The more people looking at Tapestry sources,
the better. :)
1) I agree with your suggestion. I'll do it today.
2) There's no classloading problem in this case, because the implementation of
this feature happens *before* the classes are changed. In addition, the
implementation itself, in the end, uses class names, not the class instances
themselves, as the advised method receives a String. I've chosen to model the
contributions as Class instances because it's type-safe, IDE
autocompletion-aware and less error-prone than strings. My first attempt was
using the component, mixin and page's logical names (lib/name) and advising
ComponentClassResolver, but then it didn't replace components and mixins
defined using @Component or @MixinClasses. The solution was to advise
ComponentInstantiatorSource.getInstantiator(String classname), which has no
notion of page, component or mixin. Class instances are indeed valid in
AppModule.
was (Author: thiagohp):
Hi, Lance!
Thanks for reviewing my commit. The more people looking at Tapestry sources,
the better. :)
1) I agree with your suggestion. I'll do it today.
2) There's no classloading problem in this case, because the implementation of
this feature happens *before* the classes are changed. Actually, it works in
Tapestry-IoC. In addition, the implementation itself, in the end, uses class
names, not the class instances themselves, as the advised method receives a
String. I've chosen to model the contributions as Class instances because it's
type-safe, IDE autocompletion-aware and less error-prone than strings. My first
attempt was using the component, mixin and page's logical names (lib/name) and
advising ComponentClassResolver, but then it didn't replace components and
pages defined using @Component or @MixinClasses. The solution was to advise
ComponentInstantiatorSource.getInstantiator(String classname), which has no
notion of page, component or mixin. Class instances are indeed valid in
AppModule.
> 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)
