tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Lewis Ship <hls...@gmail.com>
Subject Re: Service contributions via markers
Date Tue, 06 Jul 2010 23:58:12 GMT
Actually, that's part of what I'm doing. You should use @Marker on the
service (i.e., on its service implementation class), but use the
annotations themselves on the contribute methods:

@Marker(Red.class)
publlic class SomeServiceImpl extends SomeService { ...

@Contribute(SomeService.class)
@Red @Blue
public void providePurple() {
// Contribute to services which have Color OR Blue


Where we are differing is on that last line: should providePurple() be
invoked for SomeServiceImpl (because it has the Red marker) or NOT
(because its missing the Blue marker)?


Injection works your way, so should this.  That is, if there was an injection:

  @Inject @Color @Blue private SomeService injectionPoint;

Then we would match services that are type SomeService and have marker
annotations Color and Blue.


Here's the trick: how do you know if an annotation is a marker
annotation or not (as opposed to any other kind of annotation,
including @Match or non-Tapestry specific ones)?  I guess that an
annotation is a marker if any service any where makes it a marker.
That's going to require a big set of marker annotations inside
InternalRegistryImpl.

On Tue, Jul 6, 2010 at 4:10 PM, Robert Zeigler <robertz@scazdl.org> wrote:
> I just reread the e-mail and realized you were saying the exact opposite... that the
contributions methods should be the superset of the services... whereas I was thinking it
made sense for the service's markers to be a superset of the contribution's markers.  But
if you just changed the equals to contains all in the code, that would make the code look
for the service's markers to be a superset of the contribution's markers.  Doesn't that make
more sense?
>
> @Color @Blue
> contributeSomething(...)
>
>
> @Color
> SomeService()
>
> We probably wouldn't want contributeSomething to contribute into SomeService, because
the additional marker suggests that we are trying to contribute more specifically than just
@Color.
>
> But if we had:
>
> @Color @Blue
> SomeService
>
> @Color
> contributeSomething()
>
> Then /probably/ contributeSomething should contribute to SomeService.  That makes the
Service's markers a superset of the contribution's markers.
>
> Cheers,
>
> Robert
>
> PS: Yes, I realize my syntax for marking a service is wrong.  Consider the above pseudocode.
:)
>
> On Jul 6, 2010, at 7/65:20 PM , Howard Lewis Ship wrote:
>
>> I'm looking over this code right now, from ModuleImpl:
>>
>>    public Set<ContributionDef2>
>> getContributorDefsForService(ServiceDef serviceDef)
>>    {
>>        Set<ContributionDef2> result = CollectionFactory.newSet();
>>
>>        for (ContributionDef next : moduleDef.getContributionDefs())
>>        {
>>            ContributionDef2 def = InternalUtils.toContributionDef2(next);
>>
>>            if (serviceDef.getServiceId().equals(def.getServiceId()))
>>            {
>>                result.add(def);
>>            }
>>            else
>>            {
>>                Set<Class> markers = CollectionFactory.newSet(def.getMarkers());
>>
>>                if (markers.contains(Local.class))
>>                {
>>                    if
>> (moduleDef.getServiceDef(serviceDef.getServiceId()) == null)
>>                        continue;
>>
>>                    markers.remove(Local.class);
>>                }
>>
>>                if (serviceDef.getMarkers().equals(markers)    // Why equals()
?
>>                        && serviceDef.getServiceInterface() ==
>> def.getServiceInterface())
>>                {
>>                    result.add(def);
>>                }
>>            }
>>        }
>>
>>        return result;
>>    }
>>
>>
>> I think that's an error, comparing the services markers to the
>> contribution methods markers using equals().  I believe that should be
>> containsAll().  As in, the contribution method's annotations are a
>> super-set of the service's marker annotations.
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator of Apache Tapestry
>>
>> The source for Tapestry training, mentoring and support. Contact me to
>> learn how I can get you up and productive in Tapestry fast!
>>
>> (971) 678-5210
>> http://howardlewisship.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>



-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Mime
View raw message