Generically reading out config sections / XML

[jjvanzon]

Executed around 2013-09

A generic way to read out configuration sections. Doing it the classic way with System.Configuration may be difficult and error prone. JJ.Framework.Configuration might make it easier. Much of the processing may be delegated to JJ.Framework.Xml.

2013-09-12 Done JJ.Framework.Configuration

• Separate handling of XML attributes and elements.
• Handling of custom names
• Handling of arrays
• Custom handling of arrays.
• Reading out branches, not just leaves.
• Get array length

---

• Refactoring XmlExpressionTranslator so it is a Stack, not a Stack
• To use x => x.Array[i], maybe visiting the array index expression, visiting constant expression, putting it on the stack and popping it from it again.

---

• Design error: The static Type.GetType might do what ReflectionHelper was doing... Assume camel case, unless otherwise specified.

---

• Redesign:
• Why use interfaces to map to instead of classes?
• The XML might be deserialized to classes instead.
• It was doing it a harder way, because they were like proxies.
• Using concrete classes instead of interfaces.
• Translating XML to object graph.
• Making System.Configuration.ConfigurationManager.GetSection return the object graph.

---

• XmlToObjectConverter seems too strict. It wants the Chars property of a String type to be provided in the configuration file. Handling primitives differently or handling optional / required differently, or handle specific types as leaves.
• The configuration object structure was not cached.

2013-09-12 Brainstorm JJ.Framework.Configuration (1)

You can either handle the XML, create all those derived classes e.g. ConfigurationElement, or derive from ConfigurationSection and create all those ConfigurationProperties.

System.Configuration would handle conversion, validation and default values. Why is it an extremely confusing API? I always wonder what I have to do if I want an array, what I have to do if I want to differentiate between attributes and elements. It is always confusing what classes to derive from, what C# attributes to use and why do I have to cast so much and use those strings and dictionaries.
The array thing is very, very confusing. You have to derive a class from ConfigurationElementsCollection and give it a ConfiguraionCollection attribute, with as a parameter the type the attribute was already put on (that's stupid). And you have to override a bunch of members, then use that as a property of a configuration section. Also, it is not clear when something becomes an element and when it is an attribute. It turns out a property will be decorated with [ConfigurationProperty(...)] and it will be an attribute, unless it is of a type ConfigurationElement, which is a derived class again.

It is just too much work and it is confusing.

Why is offering a different interface better, that does not require using inheritance? I do require people to know those Xml attributes... and I also do not seem to believe in default values or offer validation.

And I do not offer saving the configuration.

2013-09-12 Brainstorm JJ.Framework.Configuration (2)

If there are xml nodes that are not in the object, then so be it.
If there are properties in the object, that are not in the xml, then make them null.
If an object property is not nullable, then throw an exception if it is not in the xml.

So now, is it better to go by the xml structure and translate it to the object, or to go by the object structure and look things up in the xml?

If you go by the object structure, you can look it up in the XML and if it is not there, then check if it is a non-nullable value type, if it is, throw an exception, if it is not, then skip the property.

If you go by the xml structure, you look up a property, if it is not there, then ignore it. If the property is there then fill it in. But then you easily accidently skip the required, non-nullable value types.

The object structure dictates more of what is expected from the XML, than the XML dictates what is expected from the object structure. For instance, the object structure dictates if it should be an element or an attribute.
Also, the XML might contain things that the object structure does not, so that would be redundant to look up.

So the object structure should be leading. However, you might want to just pass both xml node and object to each method. Then you do not need a stack.

Postponed

• ~ JJ.Framework.Configuration: Normal ConfigurationManager will not return a concrete type, but returns Xml, because I do not know the type there. So now instead you HAVE TO call my own version of the ConfigurationManager to read out the configuration at all.