Scott Hernandez wrote:
>I would agree that they do not need to be unique. But task names do,
>right?
>
yep
>
>BTW. Maybe we should use a scheme like I described below to guarantee we
>don't have dupl. task names defined. Right now, the first named task
>that matches is always returned.
>
Thats true. We definately need to trow an exception in that case.
>
>It seems like we are trying to use TaskAttributeAttribute and
>ElementNameAttribute to specify what the XML should look like for a
>given task. Maybe there are some task specific attributes that we may
>add in the future, but for now, it seems like we are just adding
>metadata (via code attributes) to help load the xml input file.
>
>So, keeping that goal in mind, it seems like we need [attribute]s that
>define just that. We have one that works for attributes,
>TaskAttributeAttribute. But ElementNameAttribute doesn't really work for
>elements. Plus, the ElementNameAttribute doesn't really help with schema
>generation.
>
>It is a little bit tricky because elements can appear multiple times.
>Maybe the correct format is to require Array Properties for all Elements
>that can have more than one. And create a new TaskElementAttribute to
>help us define it.
>
Thats what BuildElement is supposed to be used for I didn't use the name
"TaskElementAttribute" because the same attribute would be used for
elements within elements that aren't tasks. BuildElement doesn't handle
the multiple element case. I was envisaging another [attribute] for this
but if we decide to store child element lists as ElementType[] arrays
then we can overload it as you've shown below. You're correct in that we
probably don't need the ElementName attribute - I guess its a hang-over
from when Element was inserted a a base class to Task.
>We could then get rid of the ElementNameAttribute,
>and the BuildElementAttribute classes. Also, we can add more meta-data
>for schema generation and validation. (I've been looking at the xml
>serialization stuff, it could be very useful for this if we don't want
>to come up with our own.)
>
>The code would look something like this:
>
>class NewTask : Task
>{
> //attributes and props
>
> //just one element.
> [TaskElement("elementName", Required=true)]
> public myChildElement ChildElement1
> {
> set{ _local = value }
> get{ return _local; }
> }
>
> //allows for more than one xml element
> [TaskElement("elementName", Required=true)]
> public myChildElement[] ChildElement2
> {
> set{ _local = value }
> get{ return _local; }
> }
>
> protected class myChildElement
> {
> //attributes
> [TaskAttribute("foo")]
> string foo;
> }
>}
>
>Then we would change Element.InitializeAttributes to get all members
>that have a TaskElementAttribute and their return type. If the return
>type derives from Element, follow the same rules we do for
>BuildElementAttribute matches.
>
How is this different to what happens now in
Element.InitializeAttributes ?? I'm not sure what you want to change
here. The only addition I see is to handle the array case. Please
explain what you mean bout the return type here. Do you just want to
ensure that attributes are only placed on Element derived classes ?
>Else run the type though something like
>InitializeAttributes(which takes the return type). (This will go on
>recursively while there are TaskElementAttributes to process.)
>
>
>Also, I think we may want to change the Task prefix into an NAnt one. So
>TaskAttributeAttribute becomes NAntAttributeAttribute.
>
Wel lets decide on a consistent naming scheme by all means. I'm not sure
NAntAttribute is the way to go. We're inside the Sourceforge.Nant
namespace anyway, it seems to be needless duplication to say NAnt again.
Still if we can't find better names.
Ian
_______________________________________________
Nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
