Custom Schemas / Dom Gen?

43 views
Skip to first unread message

Jason Batchkoff

unread,
Dec 11, 2014, 5:27:26 PM12/11/14
to authoring-to...@googlegroups.com
I was curious how involved it would be to avoid the xsd for schema generation and use something else, like say a C# file with some markup for attributes in it.

It looks like I could provide all that info manually in a different SchemaLoader?  How involved would it be to modify DomGen to generate the appropriate information (maybe I don't need to...)?

Bill Clark

unread,
Dec 12, 2014, 4:31:56 PM12/12/14
to authoring-to...@googlegroups.com
Yeah I've got something along those lines, where the fields are defined in a json generated by our game executable. It's not too difficult to create your own SchemaLoader, and basically create a PropertyDescriptorCollection for the type and AttributeInfos for all the properties.

Looks like this, where ProcessPropertyMetadata loads and processes that json file. Here, it's loading our Item information. I'm later going to make it more generic to load arbitrary types of data. Item.Type is a static DomNodeType:

            List<AttributePropertyDescriptor> descriptors = new List<AttributePropertyDescriptor>();

            // Load the list of item properties.
            ProcessPropertyMetadata(descriptors, categoryMappings, "ItemData", "");

            Item.Type.SetTag(new PropertyDescriptorCollection(descriptors.ToArray()));

            foreach (var descriptor in descriptors)
            {
                Item.Type.Define(descriptor.AttributeInfo);

Jason Batchkoff

unread,
Dec 12, 2014, 5:44:34 PM12/12/14
to authoring-to...@googlegroups.com
Cool, that's what I was kinda gathering from reading the code myself, but it's nice to see someone else's code as confirmation.  :)

I take it you are creating the PropertyDescriptor's AND the AttributeInfo's and pair them up in your function, since the PropDesc's need the AttrInfo?

Also, is it required to have the static DomNodeType?  Seems like for most cases, when making a new DomNode, you could just look up a type via string in a Dict<string, DomNodeType>?  Other than that, I'd imagine it's a nice convention (if the type name changes, you'll get compile errors instead of runtime errors).
Reply all
Reply to author
Forward
0 new messages