I like the idea of polymorphic types, but I'm not sure about this type of
implementation - it requires that the type be a subclass of another type, and
would prohibit interface implementation from working. When I first ran into a
similar issue a while back I got to thinking that what would be a better
approach would be to pair this issue with the whole deployment descriptor
issue, and have each type optionally declare a "property" that would be used to
set it. (the DD issue comes into play because the third declaration by
necessity breaks the ability to use the simple properties file to map the
element name to the class)
By default, the property could be the type itself, e.g. <path>'s property would
be "path", <and> and <or>'s property would be "condition".
I have an implementation that I'm modifying now to serve as a proof of concept.
Its from some code I wrote last year (and currently in production) that uses a
<element> to Class mapping to parse XML into objects. Incidentally, my original
code had the same problem Ant does of assuming that the <element> was the same
as the property name. Probably because I got the idea for the code from looking
at how Ant works, but was unable to extract something generic that I could use.
:-)
I should (in between day-job and family commitments) be able to post this some
time this week.
Does the general idea though, of actually registering the property name work
for people? I think it seems fairly obvious, especially when the default is to
use the element name.
Tim
List: ant-dev <?l=ant-dev&r=1&w=2>
Subject: [IDEA] Polymorphic types <?t=100591829400008&r=1&w=2>
From: Conor MacNeill <[EMAIL PROTECTED]> <?a=100030834400001&r=1&w=2>
Date: 2001-11-16 13:50:01 <?l=ant-dev&r=1&w=2&b=200111>
[Download message RAW <?l=ant-dev&m=100591826612807&q=raw>]
Attached is a patch to the IntrospectionHelper to give a little
ploymorphic behaviour for nested elements. I haven't committed this as I
thought I'd get some reaction first.
Basically what this patch does is the following: When a nested creator
cannot be found for a particular nested element, a check is done to see
if the element corresponds to a datatype. If it does, a search is done
for a superclass of the datatype for which the class does have an addXXX
style creator.
In practice, this allows me to use derived types with core tasks without
needing to change the core task. For example, if I wanted to use a
classfileset type in a <copy> task, I do not need to change copy to add
a addClassfileSet() method. I can just use this
<copy todir="deptest">
<classfileset dir="build/classes"
baseclass="build/classes/org/apache/tools/ant/Main.class"/>
</copy>
Similarly, I can have classfilesets in jars without changing the <jar>
task.
It isn't perfect since some tasks use rolenames in their nested elements
<blah>
<fromfileset>
<tofileset>
</blah>
For these tasks, the current method of refids needs to be used.
Nevertheless, I think the patch is useful and makes it much more
meaningful to define derived types.
The patch as it currently stands is just a proof of concept. There are
some inefficiencies which can be factored out if required.
Let me know what you think?
Conor
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
