Hi Andre,
I wrote a sample for registering a custom parser - damn embarrasing as we can't use "configParsers" as the section name since
System.Configuration.ConfigurationException: Tag names beginning with config are reserved
which is what is in the latest release :oops: I'll get a cvs tarball out there with this fix asap. I've changed the name to be "parsers" instead.
That said, here is a minimal example of using a custom schema for the "TestObject" we use in the unit tests.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<sectionGroup name='spring'>
<section name="parsers" type="Spring.Context.Support.ConfigParsersSectionHandler , Spring.Core" />
<section name='context' type='Spring.Context.Support.ContextHandler, Spring.Core' />
<section name='objects' type='Spring.Context.Support.DefaultSectionHandler , Spring.Core' />
</sectionGroup>
</configSections>
<spring>
<parsers>
<parser namespace="http://schemas.springframework.net/testobject"
type="Spring.Context.Support.TestObjectConfigParser, Spring.Core.Tests" />
</parsers>
<context>
<resource uri='config://spring/objects' />
</context>
<objects xmlns="http://www.springframework.net">
<object id="Parent" type="Spring.Objects.TestObject,Spring.Core.Tests">
<property name="name" value="Parent" />
</object>
<testobject xmlns="http://schemas.springframework.net/testobject">
<age>12</age>
<name>John</name>
</testobject>
</objects>
</spring>
</configuration>
And a very simple parser is
public class TestObjectConfigParser : DefaultXmlObjectDefinitionParser
{
public TestObjectConfigParser()
{
}
public override int ParseRootElement(XmlElement root, XmlResourceReader reader)
{
return 0;
}
public override int ParseElement(XmlElement element, XmlResourceReader reader)
{
ObjectDefinitionHolder holder = ParseTestObjectDefinition(element, reader);
if (holder == null)
{
return 0;
}
ObjectDefinitionReaderUtils.RegisterObjectDefiniti on(holder, reader.ObjectReader.Registry);
//We created one object.
return 1;
}
private ObjectDefinitionHolder ParseTestObjectDefinition(XmlElement rootElement, XmlResourceReader reader)
{
MutablePropertyValues properties = new MutablePropertyValues();
XmlNodeList childNodes = rootElement.ChildNodes;
//Get the age text
string agePropValue = childNodes[0].InnerText;
properties.Add(new PropertyValue("Age", agePropValue));
string namePropValue = childNodes[1].InnerText;
properties.Add(new PropertyValue("Name", namePropValue));
IConfigurableObjectDefinition od = new RootObjectDefinition(typeof (TestObject), null, properties);
od.IsSingleton = false;
//HardCoded for now.
string id = "testObject";
//id = ObjectDefinitionReaderUtils.GenerateObjectName(od, reader.ObjectReader.Registry);
return new ObjectDefinitionHolder(od, id);
}
}
We will have to look into the ability to add object definitions to the context after it has been created. I gather the usecase you have in mind is dynamic plugins.
Allowing the Spring schema to be nested inside your schema.. To support that we would probably have to make the current Spring schema more modular so that bits of it could be imported into your schema. I never really thought of it because I thought the whole purpose of having custom schema was to get away from the generic reflection like usage and provide "domain" specific elements and attributes. Now that you mention it I can see how reusing bits and pieces maybe nice, for example lists and maps. The implementation of your parser would then probably have to call inherited methods from DefaultXmlObjectDefinitionParser, some of which are probably private now.
Cheers,
Mark