I'm with you now. Thanks. This is what I'd thought, but things get a
little confusing.
I've been thinking about this a little, maybe an attribute that defines
a delegate that should be used for schema generation would work. That
way you can centralize your code in one place, or space it out anyway
you want. It also reduces the number of classes being create/loaded. And
you can define xsd generation with the existing base Element.
Here is kinda what I'm thinking:
delegate XmlSchemaComplexType GenerateSchema (Type source)
[SchemaSource(new GenerateSchema(Generator))]
[FileSet("stuff")]
public FileSet MyStuff
{
get;
set;
}
public static XmlSchemaComplexType Generator(Type source)
{
//do generation
}
This could also work for validation. I'm not sure that validation,
property filling, and xsd generation can all be wrapped together to work
with the same [attribute]s. Maybe I'm just a little overwhelmed with all
this. I have not found the naming to be exceedingly intuitive. Maybe I'm
just not thinking right yet :)
Maybe I'm making this a little complicated?
Also, remember that I'm working with Type(s), not class instances. I
don't actually want to create tasks, just model the data. I'm happier
with statics for these types of things rather than instance methods.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Gerry
Shaw
Sent: Tuesday, April 16, 2002 9:29 AM
To: [EMAIL PROTECTED]
Subject: RE: [nant-dev] XML Schema Def (XSD)
> Could someone go into a little more detail here? (I'm a
> little knew to nant and trying to catch up :)
>
>
> -----Original Message-----
> From: Gerry Shaw
> > Why not have the element class have a default
> implementation based on
>
> > the Attributes and if a task chooses to override this for
> > some reason it can.
Provide a virtual method in the Element class that can create the schema
for that element. This implementation would simply use [attributes]
attached to the class to determine the required xml attributes and xml
child elements. Classes that inherit from Element could then override
this method and perform more sophisticated validation.
This would let for example the <touch> [1] to replace the basic runtime
syntax error check with something in the schema that would flag this
type of error before the build even started.
Other tasks like the <sleep> [2] wouldn't be able to take advantage of
this as the only time you know about the contents of the attribute is at
runtime due to macro exapansion. This isn't a problem because the
[validator] attributes normally catch most of these errors (in fact the
<sleep> task should have a number of [IntValidator] attributes attached
:)
[1]
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/nant/nant/src/NAnt/Tasks/
TouchTask.cs?rev=HEAD&content-type=text/vnd.viewcvs-markup
[2]
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/nant/nant/src/NAnt/Tasks/
SleepTask.cs?rev=HEAD&content-type=text/vnd.viewcvs-markup
_______________________________________________
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
