At 11:15 2/4/01 +0200, Stefan Bodewig wrote:
>Peter Donald <[EMAIL PROTECTED]> wrote:
>
>> At 10:53 2/4/01 +0200, Stefan Bodewig wrote:
>
>>>Pete referred to "container task", which is another request, that
>>>all people seem to agree with - i.e. extend the current API to let
>>>Tasks have arbitrary task children via something like a
>>>createTask(String) method.
>>
>> Yep but instead of adding complexity to engine I was thinking we
>> could provide a AbstractContainerTask that got passed configuration
>> and and did that "under the covers". This way everything is still
>> simple for us to maintain ;) No magic interfaces - the users are
>> given as much power as they want/can-handle.
>
>Uhm, but then only AbstractContainerTask would need to provide access
>to these child elements. Maybe I'm a little slow here.
Thats only for people who want simplicity. Theoretically any arbitrary task
could interpret it's own TOM and make a XML scripting language for hell (or
build a system like frantic inside it).
>And I was trying to simplify things when talking about container tasks
>above - I don't want to make that a task writer's responsibility
>either. Whether we do it by an abstract base task or a marker interface
>that would get some special treatment from the ProjectBuilder ...
Marker interfaces only go one level deep easily - if we use TOMs then we
can do things (as ugly as they may be) like
<if test="...">
<while test="...">
<third-layer-task ../>
</while>
</if>
or absolutely anything really ;)
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 |
*-----------------------------------------------------*
