You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by "Shackelford, John-Mason" <Sh...@ncs.com> on 2002/08/21 20:11:37 UTC
polymorphic data types as nested elements
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
shacjo@ncs.com
****************************************************************************
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: polymorphic data types as nested elements
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
By using addXXX or addConfiguredXXX you're asking Ant to create the
object for you, so it must be creatable with a no-arg constructor. An
abstract class is not - so you will get some kind of nasty error.
You need to implement the createXXX method so that you create some
concrete object to return back, but your createXXX method can be
declared to return the abstract base class if you desire (but remember
that introspection is being used, so it *will* find
setters/creators/adders on the actual object returned even if they are
not declared on the abstract base class).
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
> shacjo@ncs.com
>
> ****************************************************************************
> 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: polymorphic data types as nested elements
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
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
> shacjo@ncs.com
>
> ****************************************************************************
> 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>