I would agree that they do not need to be unique. But task names do,
right?
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.
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. 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. 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.
Does this make any sense? I could mock up an example in code if that
would help...
later
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Ian
MacLean
Sent: Friday, April 19, 2002 12:34 PM
To: Scott Hernandez
Cc: [EMAIL PROTECTED]
Subject: Re: [nant-dev] ElementNameAttribute and BuildElementAttribute
Scott Hernandez wrote:
>Looking through the code I found that both NUnit.FormatterElement and
>TStampTask define an element named "formatter". I know this is fine
now,
>since you looking at TaskNameAttributes, but should this be fixed?
>
I'm not sure these element names need to be unique. The tStamp task is a
completely different context from a NUnit formatter so it shouldn't
matter. Then I guess we can't lookup an element class based on element
name alone - we'd need to pass some scope information as well - like the
name of the parent element. hmm it would be simpler to make them unique
but that doesn't seem right. Kinda like saying that local variable names
should be unique across a program regardless of scope.
thoughts
Ian
>
>If these are to be unique, it might make sense to keep a static class
>that can be used to guarantee this type of uniqueness within the
>ElementNameAttribute class.
>
>Something like a thread-safe version of this?
>
>static StringCollection ElementNames = new StringCollection();
>
>public ElementNameAttribute(string name) {
> if(ElementNames.Contain(name)
> //throw exception!
> else
> ElementNames.Add(name);
>
> _name = name;
>}
>
>
>Or am I missing something about the design here?
>
>-----Original Message-----
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]] On Behalf Of Ian
>MacLean
>Sent: Monday, April 15, 2002 7:17 PM
>To: Scott Hernandez
>Cc: [EMAIL PROTECTED]
>Subject: Re: [nant-dev] ElementNameAttribute and BuildElementAttribute
>
>Scott Hernandez wrote:
>
>>I don?t know much about the development history so this may be a dumb
>>question.
>>
>>Is there a reason that BuildElementAttribute isn?t derived from
>>ElementNameAttribute.
>>
>Yes. they are performing different tasks. ElementNameAttribute is used
>to associate an xml element name with a particular class thats being
>used to model that element. BuildElementAttribute indicates that the
>current property models a child element in the build file and gives the
>name of that element. When NAnt starts up it scans all relevent
>assemblies for classes with ElementNameAttribute 's and essentially
>builds a lookup table mapping element name to class. Then when
>tasks/elements are being loaded from the build file the
>BuildElementAttributes are used to know what child elements to select
>from the build file ( using xpath ).
>
>If you look thru the source you'll see that this isn't *quite* true -
on
>
>startup it looks for TaskNameAttribute's not ElementNameAttribute 's -
>thats because I haven't finished generalising all that code. Now that
>you remind me I should get that done pretty soon.
>
>you'll notice also that ElementNameAttribute is only relevant on class
>declarations while BuildElementAttribute applies to Property
>declarations. Having one derive from the other really wouldn't make
much
>
>sense.
>
>I hope this clarifies things
>
>Ian
>
>>It seems like they both define named Element nodes, the former being
>>handled in a more specialized way in the Element InitializeAttributes
>>method.
>>
>>Thanks,
>>
>>Scott
>>
>>PS. I tried looking in the archives, but found sourceforge?s archive
>>viewer horrible. I have since subscribed this list on
>>www.mail-archive.com <http://www.mail-archive.com/> . This is
>>searchable?
>>http://www.mail-archive.com/nant-developers%40lists.sourceforge.net
>>
>
>
>
>
>_______________________________________________
>Nant-developers mailing list
>[EMAIL PROTECTED]
>https://lists.sourceforge.net/lists/listinfo/nant-developers
>
>
_______________________________________________
Nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
_______________________________________________
Nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
