[ 
https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795053#comment-13795053
 ] 

Lance edited comment on TAP5-1611 at 10/15/13 10:46 AM:
--------------------------------------------------------

Yes, this was the sort of ClassCastException I was referring to. But if you 
instead declared:

{code}
@InjectComponent
private FormValidationControl form;
{code}

You could use interfaces to defensively future proof your code for component 
overrides.



was (Author: uklance):
Yes, this was the sort of ClassCastException I was referring to. But if you 
instead declared:

{code}
@InjectComponent
private FormValidationControl form;
{code}

You could use interfaces to defensively code against component overrides.


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

Reply via email to