tapestry-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
Date Tue, 15 Oct 2013 13:50:42 GMT

    [ 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)

Mime
View raw message