Jose Alberto Fernandez wrote:
> What does it all mean? It means we can now write a task, well typed, which
> can be accept different XML subelements depending on the declarations of
> other objects present on the build. The vendor specific elements of
> <ejbjar>, <jspc> and others are typical examples of where this capability
> can be very useful. Other parts of core could benefit of course.
Let me see if I understand corectly what you want.
You'll have a task TaskA, with a method "addRoleB".
And in XML:
<taskA ...>
<implementationB1 >
</taskA>
TaskA doesn't know anything about the implementation - it will only use an
interface ( or base class ) "RoleB" as parameter.
I assume you will need some way to associate the tag <implementationB1> with
a particular class - and this can be very well be done currently with
<taskdef> or <typedef> ( or with the new "role" declaration if you want ).
In any case, all you really need is the tag name and the class name - the
roles will be available as interfaces or superclasses. Nothing special for
this association.
The second part is making IntrospectionHelper recognize a child that
doesn't fit the current patterns ( i.e. no addImplementationB1 ), and
instead of reporting an error look up the child by the name and create the
type, then check the interfaces implemented by the class and see if any
method in the parent matches.
Is there anything else ?
> 2) What do they do that is no possible in ANT:
>
> They allow IntrospectionHelper to connect an XML subelement eventhough
> introspection cannot find a create or add/Configured method for it.
> It is a well typed methanism, the parent object will only be passed
> objects that it knows how to deal with. And the parent object does not
> need to have any knowledge of what currently available members are on the
> role.
Yes, parent needs one addXXX method with a typed parameter, and the child
needs to be matched against it.
What I don't understand is why should we just use the existing typedef and
just add this new pattern to IntrospectionHelper.
> Also notice that Roles do not supercede DynamicConfigurator. On one hand
> roles let external implementations to be considered as possible
> subelements of a parent object, on the other hand, DynamicConfigurator
> allows a node to decide given its current state what is the meaning of a
> particular element. This cannot be done by roles in the general case, and
> that is good.
>
> Usage of Roles:
> ==============
> The principle is very simple:
>
> a) A role is defined by an interface. This interface is the parameter
> for a new special family of addConfigured(<interface>) methods.
+1 on role defined by an interface ( or base class - I don't see any reason
to restrict it to only interfaces ).
I'm not sure a special name is actually required ( addConfigured) - just an
add or set method with the interface/class as parameter, and then match
them on type.
> b) When IntrospectionHelper fails to find a create/add method for the
> element, it will look at all the roles used in the addConfigured
> methods and on each of those roles will try to find an object declared
> with that element-tag name. If one and only one match is found then
> the instantiation is successful and the new object will be configured;
> otherwise it is an error and parsing stops.
I disagree here. If the role is associated with an interface, then the
"declaration" is part of each task/type class. If you implement/extend that
interface/class - then you have this role. Any extra declaration is
redundant - unless you want to declare a wrapper ( see below ).
> c) The configured object may or may not implement the Role interface,
> if it does not, an Adaptor object may be instantiated as a proxy
> for the object. Which adaptor is used depends on how the implementation
> was declared.
+1 here - I think the "taskdef/typedef" declarations ( which I would like
merged in a single "component" declaration ) should take an extra "adapter="
attribute, to allow this wrapping.
> d) The resulting object is passed as an argument to the addConfigured()
> method.
+1 ( with the comments above ).
> Declaration of roles:
> ====================
>
> A role definition associates a name with an (Interface,Adaptor) pair.
> The only reason for associating a name with the role is to ease notation
> when declaring members of a role.
Why ?
All the user needs to do is associate a name with an implementation class.
You need the impl. class anyway - and so the name, but the roles will
be available as soon as you have the impl. class. You only need an
additional attribute if you want to wrap.
> Notice that the same interface or the same Adaptor may appear in multiple
> declarations. This only means that depending on the name used the adaptor
> of choice will be different.
>
> There can only be one pair associated with each name.
I don't see any reason for that. A class can implement multiple interfaces,
so it can have multiple roles. No need to add arbitrary restrictions.
> Declaration of implementations (members):
> ========================================
>
> A class is declared as belonging to a role by specifying the name to be
> used when appearing in that role. The same class may belong to multiple
> roles and may specify the same or different names on each one.
>
> The name used for the role during the declaration only determines which
> Adaptor will be available, if required.
>
> Within a role-interface there can only be one object associated
> with each name.
>
> Scoping rules:
> =============
>
> This is probably the more dificult aspect since given the way
> <ant> and <antcall> work it means possible redeclarations on every
> level of recursion. Whether declarations should just supercede
> one another or be smarter is something to look into.
I'll let other comment on this :-)
> Syntax:
> ======
>
> I have left out the issues of how the syntax looks like on purpose.
>
> Syntax is just that and I am sure we can reach agreement somehow.
> It is also clear that we should provide tasks to define roles
> and declare members of roles direclty on the build.
>
>
> Ok, this is it. If you have any strong opinons about it, let me know.
You already know my strong opinion.
I think we should either use <taskdef>/<typedef> - with the additional
attribute for the adapter - or use a new element <component> ( or even
<role> - but I don't find this very intuitive ) that will replace both
<taskdef> and <typdef>.
For example:
<component name="elementName" className="...." [adapter="...."] />
Costin
>
> Jose Alberto
>
>> -----Original Message-----
>> From: peter reilly [mailto:[EMAIL PROTECTED]
>> Sent: 25 April 2003 13:22
>> To: Ant Developers List
>> Subject: Re: antlib
>>
>>
>> On Friday 25 April 2003 12:24, Jose Alberto Fernandez wrote:
>> > Peter,
>> >
>> > this is exactly my point. For every new thingy that we add
>> we now need to
>> > go and modify IntrospectionHelper or something to make
>> special allowances
>> > for it.
>>
>> The dynamicelement addition to IntrospectionHelper is general
>> and new thingies
>> can be added without affecting core ant.
>>
>> >
>> > It is bloating the core like mad and in my opinion it is
>> crazy. We need a
>> > unified way to treat this things no matter what the things
>> are. Ant's
>> > engine core should not need to know anything about anything.
>>
>> Dynamicelement has the potential to remove code (e.g. all the
>> add<NAME> methods to conditionbase, selectorbase, and
>> filterchain). The
>> only problem is name clashes.
>>
>> >
>> > In an ideal world, we should have an engine core with no
>> reference to any
>> > task/type or its implementing classes and a core-antlib
>> which provides the
>> > classes and definintions for all the
>> > task/types/conditions/selectors/mappers that define core java.
>>
>> This can be done with dynamicelement, except for name clashes
>> and mapper
>> (which does not use sub-elements for different filenamemappers).
>>
>> Peter.
>>
>> Ps: I am including mods to IntrospectionHelper.java and
>> DynamicElementHelper.java
>>
