tapestry-dev 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 Mon, 16 Jun 2014 09:29:03 GMT

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

Lance edited comment on TAP5-1611 at 6/16/14 9:28 AM:
------------------------------------------------------

Thanks v. much for the impl but I have a couple of issues.

1. I think ComponentReplacer should be called ComponentOverride to be consistent with [ServiceOverride|http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/ioc/services/ServiceOverride.html]

2. Tapestry has complex classloading for component classes and I don't feel that java.lang.Class
instances for components are valid in an AppModule (the class can change in development mode
and will not be equal over time). I feel that it should be strings instead.

eg
{code}
    public static void contributeComponentClassResolver(Configuration<LibraryMapping>
config, Logger log) {
        config.add(new LibraryMapping("lib1", "foo.bar.lib1"));
        config.add(new LibraryMapping("lib2", "foo.bar.lib2"));
    }

    public static void ContributeComponentOverride(MappedConfiguration<String,String>
config) {
        config.add("lib1.someComponent", "lib2.someComponentOverride");
    }
{code}


was (Author: uklance):
Thanks v. much for the impl but I have a couple of issues.

1. I think ComponentReplacer should be called ComponentOverride to be consistend with [ServiceOverride|http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/ioc/services/ServiceOverride.html]

2. Tapestry has complex classloading for component classes and I don't feel that `java.lang.Class`
instances for components are not valid in an AppModule (the class can change in development
mode and will not be equal). I feel that it should be strings instead.

eg
{code}
    public static void contributeComponentClassResolver(Configuration<LibraryMapping>
config, Logger log) {
        config.add(new LibraryMapping("lib1", "foo.bar.lib1"));
        config.add(new LibraryMapping("lib2", "foo.bar.lib2"));
    }

    public static void ContributeComponentOverride(MappedConfiguration<String,String>
config) {
        config.add("lib1.someComponent", "lib2.someComponentOverride");
    }
{code}

> 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-core
>    Affects Versions: 5.3
>            Reporter: Jens Breitenstein
>            Assignee: Thiago H. de Paula Figueiredo
>            Priority: Minor
>              Labels: component, month-of-tapestry
>             Fix For: 5.4
>
>
> 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.2#6252)

Mime
View raw message