I guess I did not completely answer your question, but the value of XXX
is to have a different element name than its type. For example, the
<war> task supports a <webinf> sub-element. But that corresponds to the
FileSet type, as does the <classes> sub-element, and the <metainf>
element, etc. So a task can support multiple elements of the same type
easily.
Am I getting warmer?
Erik
Shackelford, John-Mason wrote:
> Greetings all,
>
> Having combed through Hatcher & Loughran's chapter on writing custom tasks
> (very good BTW),
> I am still a bit perplexed as to how ant resolves addXXX calls against
> nested tags. What is not clear to me is how the XXX portion is used in
> conjunction with the argument type.
>
> I have a task which is responsible for processing commands. I define an
> abstract class which extends DataType and then subclass it for various
> commands: Get, GenericCommand, etc. The addXXX method on my command
> processing task can then take an AbstractCommand object to work its magic.
>
> If I write the addXXX signature as: addAbstractCommand(AbstractCommand c),
> will the nested command objects be properly populated even if they contain
> getters and setters which are not overriden from AbstractCommand? Do I need
> to add multiple addXXX signatures: AddGet(AbstractCommand c),
> AddGenericCommand(AbstractCommand c). (This seems completely backwards). In
> short, what is the cash value of the XXX portion of addXXX if we can
> determine type info from the argument?
>
> Probably I am missing something basic. Forgive me.
>
> John-Mason Shackelford
>
> Software Developer
> NCS Pearson - Measurement Services
> 2510 North Dodge St.
> Iowa City, IA 52245
> 319-354-9200x6214
> [EMAIL PROTECTED]
>
> ****************************************************************************
> This email may contain confidential material.
> If you were not an intended recipient,
> Please notify the sender and delete all copies.
> We may monitor email to and from our network.
> ****************************************************************************
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>