From: "Peter Donald" <[EMAIL PROTECTED]> > On Fri, 15 Feb 2002 10:44, Conor MacNeill wrote: > > > > In addition, the way I implemented <scriptdef> it can support nested > > elements, which are potentially repeated > > > > <scriptedTask> > > <fileset ...> > > <fileset ...> > > </scriptedTask> > > > > It is hard to support that capability with simple named parameters. > > > > Thoughts? >
I really like it. Besides the fact that the syntax is consistent with the rest of ANT, it really allows for te users of the task not to know how the task was written. And given the fact than in ANT2 one is able to import/include other project files the users of this task may be different from the person that develops it. I would like to support this kind of thing in ANT1. Connor, can you tell us how do you do to introspect the class? What would need to be different to make it possible in ANT1? > The way I did it was > > <scriptdef ... > > <!-- for concrete implementations --> > <element name="x" type="o.a.ant.FileSet"/> > <!-- for stuff sucked out of registry --> > <element name="x" role="o.a.ant.Condition"/> > </scriptdef> > > The same thing was repeated with the template task and a few other tasks that > defined task-like facades. > Sorry Peter but :-p It is very very bad syntax. Imagine that all ANT syntax where like that, would you still use it? Having to learn and name all the Java classes all over the code? BTW, in both implementations, can you please make certain that script writers cannot get access to the internals of ANT by using this tasks? They should have just the same amount of power or less than the one we expect other Java code to have. Unfortunatelly, since they use reflection to find their way, it is very easy for them to cross interface boundaries and get hold to any public method of an object. This is part of the problem with <script> and the main @[EMAIL PROTECTED]&^ing reason why any tiny change on ANT1 may become backward incompatible. I thik you guys need to make sure that you interpose proxys that only allow them to access what they are suppose to and no more. And I do not think that things like creating/manipulating targets on the fly is such a good idea, they can play havoc with the dependencies. Keep the good work, Jose Alberto -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
