[
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795190#comment-13795190
]
Lance edited comment on TAP5-1611 at 10/15/13 1:48 PM:
-------------------------------------------------------
I'm agreeing with you that there are certain cases where the override MUST
extend the component it is overriding. And that tapestry will blow up in these
cases where it tries to push a round peg in a square hole (hopefully with a
nice error message).
But there are many cases where it is perfectly valid for a component override
to be a totally different implementation. As long as it has the same parameters
(and maybe a common interface). There will be times when you want to override a
component with private fields that can't be accessed. In these cases, it would
be nice to "start afresh" instead of being forced to inherit from the component
being overridden.
was (Author: uklance):
I'm agreeing with you that there are certain cases where the override MUST
extend the component it is overriding. And that tapestry will blow up in these
cases where it tries to push a round peg in a square hole (hopefully with a
nice error message).
But there are many cases where it is perfectly valid for a component override
to be a totally different component. As long as it has the same parameters (and
maybe a common interface). There will be times when you want to override a
component with private fields that can't be accessed. In these cases, it would
be nice to "start afresh" instead of being forced to inherit from the component
being overridden.
> 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)
