[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795323#comment-13795323
]
Thiago H. de Paula Figueiredo commented on TAP5-1611:
-----------------------------------------------------
I think Barry's suggested additional checks would be quite difficult and
time-consuming to implement, if even feasible. Regarding @InjectContainer and
@InjectComponent, this kind of error can already happen in Tapestry right now,
without component substitution, so I think no added checks are needed. Anyway,
the ideal is to have the field as generic (to the top of the class/interface
hierarchy) as possible, as in pure, non-Tapestry OOP best practices, avoiding
concrete classes and favoring interfaces when possible (Field instead of
TextField, etc).
I agree with Lance's suggestion that the contribution to the service should be
a logical name, not the page/component/mixin class, as the service
(ComponentClassResolver) methods will need to advise take a logical name as a
parameter : resolvePageNameToClassName(String),
resolveComponentTypeToClassName(String), resolveMixinTypeToClassName(String).
> 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)
