On 02 Apr 2001 11:36:59 +0200, Stefan Bodewig wrote: >Peter Donald <[EMAIL PROTECTED]> wrote: > >> 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 ;) > >Making <while> know its children, but not <if> know its grand children, >so what? If <if> needs to know, then <while> could expose them. > >Still cannot see the benefit of all this, make my vote a -0 as I don't >really see a reason (apart from API bloat) against "give tasks access >to their Task Object Model" either, so I couldn't really justify a >veto. >
I would think that an extended task API beyond create could be used for flexibility we need without having to go to a full XML parse by the task. Something that passes the sub-element name and the suggested class name (based on however we are reading these mappings in) to the class along with the helper. The default behavior is imply for the Task to turn around and tell the helper to do its magic, but sub-classes could override, perhaps still calling the helper API after making some changes (like changing the class). dave
