Return-Path: 
 <ant-dev-return-20577-qmlist-jakarta-archive-ant-dev=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-dev-archive@apache.org
Received: (qmail 50398 invoked from network); 30 Nov 2001 15:02:26 -0000
Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131)
  by daedalus.apache.org with SMTP; 30 Nov 2001 15:02:26 -0000
Received: (qmail 19080 invoked by uid 97); 30 Nov 2001 15:02:17 -0000
Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org
Received: (qmail 18933 invoked by uid 97); 30 Nov 2001 15:02:16 -0000
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:ant-dev-subscribe@jakarta.apache.org>
List-Help: <mailto:ant-dev-help@jakarta.apache.org>
List-Post: <mailto:ant-dev@jakarta.apache.org>
List-Id: "Ant Developers List" <ant-dev.jakarta.apache.org>
Reply-To: "Ant Developers List" <ant-dev@jakarta.apache.org>
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 18918 invoked from network); 30 Nov 2001 15:02:15 -0000
Message-ID: <005201c179af$759dfb50$0100a8c0@jose>
From: "Jose Alberto Fernandez" <j_a_fernandez@yahoo.com>
To: "Ant Developers List" <ant-dev@jakarta.apache.org>
References: <m3vgfsv2th.fsf@bodewig.bost.de>
Subject: Generic Element Containers (generalization of TaskContainer)
Date: Fri, 30 Nov 2001 14:57:14 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Stefan point about making <fail/> contain conditions brings back =
something
I have been thinking about for a while.

Today, we have special treatment of TaskContainer which allows a task
to declare that any task (or DataType) can be defined as nested =
elements.

But more and more we have other Tasks that can be containers for some =
particular
subset of elements. The typical example is <condition>. Today the way we =
deal
with this is to add new methods to <condition> every time we define a =
new
<conditional> quite unmanageable when we keep on adding more and more
conditions, almost unmannageable now that we may have two or three =
different
containers, and really unmanageable if we ever provide pluggable user =
defined=20
conditionals.

The same occurs for <mappers> <cullers>, etc. Specifying implementation =
class
names looks really awfull.

Can we come-up with a way to generalize what we do for TaskContainer?
If we provide a way for the Container to indicate which king of thing it =
can contain
then the problem could be solved. Some possible approaches would be:

    interface ElementContainer {
        String getElementsCathegory() // The name of the cathegory in =
which to search
        void addElement(Object element)
    }

So rather than having seratetly managed hashtables for different things =
we could have
one unified symbol table controlled by ANT in which things are =
registered by cathegory:
task, condition, datatype, culler, mapper, etc.

When you decare an object to ANT, like with my infamous <antlib/> you =
specify
onder which cathegory(ies) you want it declared:

    <antlib>
        <element name=3D"echo"=20
                        class=3D"org.apache.tools.ant.taskdefs.Echo"
                        cathegory=3D"task" />
        <element name=3D"glob"
                        class=3D"...."
                        cathegory=3D"mapper" />
    <antlib/>

I think this would provide a quite extensible, easy to manage and =
consistent mechanism.

And yes, there should be no problem on keeping backward compatibility.

Thoughts...

Jose Alberto
=20


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>