You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Stefan Bodewig <bo...@apache.org> on 2001/04/02 10:20:20 UTC
Re: [DISC] Task API
Glenn McAllister <gl...@somanetworks.com> wrote:
>> * tasks should have access to its own XML representation.
>
> As Peter said, replace the phrase "XML representation" with "Task
> Object Model", and I'll +1 this.
And what would this TOM be?
Tasks already have access to all attributes and all child
elements. Are you talking about a more generic interface to access
them like "Map getAttributes()" or "List getChildern()"? How and under
what circumstances would a task benefit from it?
Stefan
Re: [DISC] Task API
Posted by Peter Donald <do...@apache.org>.
At 10:37 2/4/01 +0200, Stefan Bodewig wrote:
>> When it is a container task or a dynamic one like proposed for
>> property. ie
>>
>> <if test="...">
>> <some-other-task/>
>> </fi>
>
>I still don't get it, sorry. Somehow If.createTask("some-other-task")
>or similar would have been called anyway, wouldn't it?
Okay .. now I don't get it ;)
If we use our current model it is impossible for task to contain arbitrary
sub-elements. If instead the task gets passed a full DOM/TOM/Object tree it
can interpret the tree itself in a completely random way ;) If you have a
look at mymidon proposal you will see that the property task did just that.
I can't see another clean way of doing containerships (considering that in
our case the contained objects are themselves proxy representations of
other tasks).
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: [DISC] Task API
Posted by Stefan Bodewig <bo...@apache.org>.
Peter Donald <do...@apache.org> wrote:
> At 10:20 2/4/01 +0200, Stefan Bodewig wrote:
>>Glenn McAllister <gl...@somanetworks.com> wrote:
>>
>>>> * tasks should have access to its own XML representation.
>>>
>>> As Peter said, replace the phrase "XML representation" with "Task
>>> Object Model", and I'll +1 this.
>>
>>And what would this TOM be?
>>
>>Tasks already have access to all attributes and all child
>>elements. Are you talking about a more generic interface to access
>>them like "Map getAttributes()" or "List getChildern()"? How and
>>under what circumstances would a task benefit from it?
>
> When it is a container task or a dynamic one like proposed for
> property. ie
>
> <if test="...">
> <some-other-task/>
> </fi>
I still don't get it, sorry. Somehow If.createTask("some-other-task")
or similar would have been called anyway, wouldn't it?
Stefan
Re: [DISC] Task API
Posted by Peter Donald <do...@apache.org>.
At 10:20 2/4/01 +0200, Stefan Bodewig wrote:
>Glenn McAllister <gl...@somanetworks.com> wrote:
>
>>> * tasks should have access to its own XML representation.
>>
>> As Peter said, replace the phrase "XML representation" with "Task
>> Object Model", and I'll +1 this.
>
>And what would this TOM be?
>
>Tasks already have access to all attributes and all child
>elements. Are you talking about a more generic interface to access
>them like "Map getAttributes()" or "List getChildern()"? How and under
>what circumstances would a task benefit from it?
When it is a container task or a dynamic one like proposed for property. ie
<if test="...">
<some-other-task/>
</fi>
or
<property name="foo">
<somedatatype ...>
.....
</somedatatype>
</property>
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*