To answer your last question first, I don't have any estimate to time or
effort this would take. I think we still need to work out the details.
See my other comment inline.
> -----Original Message-----
> From: Ian MacLean
> Sent: Wednesday, May 01, 2002 11:26 AM
> To: Scott Hernandez
> Cc: [EMAIL PROTECTED]
> Subject: Re: [nant-dev] Issues Related to Schema Generation of NAnt
Tasks
[snip]
> >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.
Let me address this after we talk a little more about how the new
attributes will work.
>
> >
> >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.
I do too. I think they will offer the solution to 80-90% of the
problems. I can only imagine a few situations where someone might want
to add more information by directly affecting the XSD generation.
We will need to allow access to the XSD Generation process. But we can
address that when we encounter a scenario that attributes don't handle.
> >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.
Is there some problem using the field/property name as the xml attribute
name?
>
> I can see
>
> [XmlArray("formatter")]
> [XmlArrayItem (typeof(FormatterElement)]
> FormatterElement[] formatters;
>
> working well for repeating elements.
Let's start a new thread dedicated to defining the new code attributes
that we will need (as well as changes to the existing ones).
>
> 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
What do you want to preserve support for? The file format? In my
opinion, that is a good idea. But if we change things we can always
supply an xslt to convert the build file. We can even host a page that
does the transformation, and validation, on the NAnt sourceforge site.
> XmlAttrbuteAttribute, XmlElementAttribute, XmlArrayAttrbute and
> XmlArrayItem ( or classes derived from them ) give you enough
> information to auto-generate schema's ?
I think that with a combination of the XML Serialization Attributes we
can do it. I don't want to speak too early, so let me leave it at
probably.
If we want to go this route, I can try to have a converted code-base by
the end of the weekend. I expect this will be a sandbox project where I
won't check anything in till everything is converted over. (by the end I
start making commitments...)
_______________________________________________________________
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
