From ant-dev-return-22652-qmlist-jakarta-archive-ant-dev=jakarta.apache.org@jakarta.apache.org Wed Jan 09 08:44:55 2002 Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 1868 invoked from network); 9 Jan 2002 08:44:55 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 9 Jan 2002 08:44:55 -0000 Received: (qmail 2151 invoked by uid 97); 9 Jan 2002 08:44:51 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 2069 invoked by uid 97); 9 Jan 2002 08:44:47 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 2036 invoked from network); 9 Jan 2002 08:44:43 -0000 Message-ID: <002001c198e9$3af0dc30$0100a8c0@jose> From: "Jose Alberto Fernandez" To: "Ant Developers List" References: <200201070438.g074coa30412@mail012.syd.optusnet.com.au> <000a01c197c9$7c0900b0$0100a8c0@jose> <200201081137.g08BbZc26979@mail016.syd.optusnet.com.au> Subject: Re: IntrospectionHelper request Date: Wed, 9 Jan 2002 08:40:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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 From: "Peter Donald" > On Tue, 8 Jan 2002 09:20, Jose Alberto Fernandez wrote: >=20 > > This is fine. The only thing I would ask (and notice I have not = looked at > > your code) is whether you plan to use the same mechanism for > > TaskContainers. There is certaintly no reason whatsoever to have two > > different mechanisms for what it is exactly the same issue. >=20 > Theres no distinction between TaskContainers and other sorts of = containers.=20 > However I don't think that a similar mechanism will be used. In the = case of=20 > TaskContainers et all you are not dealing directly with tasks but with = > TaskModels - so in this case it would be much more beneficial to have = the=20 > "container" passed the TaskModel and it can interpret it as = appropriate.=20 >=20 > The mechanism described above is more orientated to adding a concrete=20 > implementation of a abstract type rather than adding and possibly=20 > implementing tasks according to specified rules and behaviour. >=20 > If you can think of a mechanism that would be easy to support both use = cases=20 > easily then I am all ears. >=20 Once again you speek in riddles :-) Maybe I have to spend time on your code, or maybe you could give us an = intro to the design of myrdom(sp?), you have generated way too much code for = me to have the time to digest it. In any case, when I write a Task that can have elements that are tasks = (TaskContainer) or one that can have mappers, there should be no difference from the = task writer point of view on how to write its set/add methods. Of course it may be that for a = TaskContainer the argument is not ot type Task, but some other thing like a TaskModel = that you mention and I am not sure I understand. But the point is that whtever it is, it = should be based on the same discovery mechanism that you describe for the other : "based on the "add" method signature, reverse map to a role and then = search on the role's registry for an entry for the corresponding element". JA -- To unsubscribe, e-mail: For additional commands, e-mail: