Scott Hernandez wrote:
>
>Here are the basic problems with code attributes:
>
>1.) Not everything is defined with NAnt Attributes. Take a look at
>FileSet. The includes and excludes elements are read thought the
>InitializeElement(XmlNode elementNode) method.
>
>2.) BuildElementAttribute does not specify number of elements. There is
>no way to tell how many elements are required.
>
I agree with both of these points. This had been kinda evolving but
never got properly done
>
>3.) BuildElementAttribute requires that you derive your class from
>Element. This is limiting and causes more of 1.
>
What is the main limitation here ? Right now all the serialization code
is in Element so that each element can de-serialize itself and its
children. Is there anough of a limitation to justify moving this code
out to an external NAntSerializer class or somthing like that.
>
>That leaves us two solutions (that I can think of). Either enhance the
>code attributes or add code to supply this extra information.
>
>Code Attributes
>Pros: Simple, Easy to use, intuitive?
>Cons: Harder to extend, need to take into consideration each new code
>attribute in core/framework, get much more complicated as the xml does.
>
I'd lean towards more informative attributes.
>
>This problem is really making me think hard about using the XML
>Serialization Attributes. All of these problems have already been solved
>there, and there is also support for XSD generation.
>
How do you see this working ? replacing BuildElementAttribute and
TaskAttributeAttribute with XmlElement and XmlAttribute ? How about
having classes that derive from XmlElementAttribute ? the reason I'd
like this is because XmlAttributeAttribute for example can be used with
an empty constructor
[System.Xml.Serialization.XmlAttributeAttribute()]
public string id;
whereas we'd like to enforce an attribute name passed as a minumum. We
probably also want to enforce the attributes being on Property declarations.
I can see
[XmlArray("formatter")]
[XmlArrayItem (typeof(FormatterElement)]
FormatterElement[] formatters;
working well for repeating elements.
Whats your estimate on how much effort there is in this and what impact
this will have on the current code-base. ? I'd like to preserve the
current de-serialization mechanism if possible - adding support for
XmlArray types. Would using a combination of
XmlAttrbuteAttribute, XmlElementAttribute, XmlArrayAttrbute and
XmlArrayItem ( or classes derived from them ) give you enough
information to auto-generate schema's ?
Ian
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
_______________________________________________
Nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
