You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tapestry.apache.org by "Jens Breitenstein (JIRA)" <ji...@apache.org> on 2011/08/15 21:33:28 UTC
[jira] [Updated] (TAP5-1611) out-of-the-box way in Tapestry for
replacing components
[ https://issues.apache.org/jira/browse/TAP5-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jens Breitenstein updated TAP5-1611:
------------------------------------
Description:
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.
was:
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.
> 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
> 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 is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira