tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thiago H. de Paula Figueiredo (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TAP5-1611) out-of-the-box way in Tapestry for replacing components
Date Tue, 15 Oct 2013 15:48:44 GMT

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

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

> 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

View raw message