Thanks, this is good summing up. On 9/13/06, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> Sorry I did not read all the svn commit emails. Which classes implement these role definitions ? None, at least none that "define" a role. Peter has extended IH and co. to lookup nested-element in tasks/types that have add(X)-type methods, in a new mapping he called restricted types (because they cannot use by themselve, only as nested element of declared tasks/types). Suppose I write FooTask in my bar AntLib. If FooTask as a add(Condition) method, as of now, I can only use as nested elements conditions which have been explicitly typedef'd. Currently, there are none in Ant.
Except for isfileselected and scriptcondition. There is an antlib.xml for conditions, but I'm forced to explicitly
load it to be able to use them in my FooTask, and doing so I bring them all into the "global" tasks/types mapping, so they can be used at the top-level in <project> or <target>. Peter's "restricted" types form a new mapping (I would normally say a new namespace, but it becomes confusing because of XML namespaces...), which is used exclusively to resolve add(X)-type methods. This new mapping doesn't define any roles. The role that one of this mapping will play in a task will depend on (1) the add(X) method of that task, and (2) the types this one mapping is compatible with (in the sense of instanceof or Class.isAssigneableFrom). So there's no real notion of a role, IMHO. Which is why I'm not fond of using <roledef> to declare this "restricted" types. I believe Peter now added a 'restrict' attribute to <typedef>, which I'm also not fond of, but it may turn out to be the less controversial choice... No code to look at yet, since I don't think Peter posted his diffs to BugZilla yet. --DD
I will soon... Peter ---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
