You've probably read a lot by now about the tension between the OO purist view of the world and the XML purist view of the world. You might also have picked up that I personally find myself more at the XML end of the spectrum, due in no small part to the influence of Tim Ewald.
One day not too long ago, Tim rang me up to tell me about a revelation he had had. He used to hate XmlSerializer because it embodies the fallacy that there's an isomorphism between objects and XML. But he explained to me that if you looked at it in a different way - simply as a convenient mechanism for populating a set of variables - that it wasn't so bad. The idea being that in order to code against the XML, you're going to have to find a way to pull the data out and get it into variables. XPath is one way to do that, but so is XmlSerializer. I generally followed his argument at the time, but it didn't really sink in until recently.
I was trying to rewrite some of the configuration code I'd done for one of my clients. The issue was that we have a whole bunch of web projects, and having to make changes in 17 different web.config files was annoying. So I wanted to set it up so we could simply point to a single config file in a well-known directory.
I started off using a modified version of my XmlSerializer configuration section handler. But as I was looking at it, I realized that there was a better way. As it stands, the section handler expected XML in the config file that looks like this:
<configuration>
<!-- configSections element goes here -->
<MyStuff type="SomeNamespace.MyStuff, CraigsConfig">
<Foo>1.234</Foo>
Hi, you may probably interested in the Configuration Management Application Block created by Patterns And Practices Group in Redmond (i have coded the block).
ReplyDeletehttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/cmab.asp
This block solves the problem you describe here, and also allows a Write interface to the configuration can be changed by the applicatoin. Of course any IConfiguratoinSectionHandler can be reused with this block.
Hope you like it.
Diego Gonzalez
Lagash Systems SA
Funny, my compiler refuses to allow the above code because "No overload for method 'GetConfig' takes '2' arguments". I was able to get your old XmlSerializerSectionHandler to return a fully instantiated MyStuff object, but it never read the values out of the .config file.
ReplyDeleteDiego: yep, I'm looking at CMAB right now. It's pretty cool, but it makes you put the type in the XML, which is unfortunate for the reasons I outline here. We'll likely wind up using CMAB in our code because it's pretty cool.
ReplyDeleteflipdoubt: The code I wrote was conceptual: it wasn't meant to compile. I probably should have written it as something like MyConfigurationSettings.GetConfig(typeof(SomeOtherType), "MyStuff"). Sorry for the confusion!
Craig: Cool handler for providing for various types in the .config -- any ideas or suggested examples on writing to a user-specific config (from you or from others)? Many samples I've found seem to assume you either want to mess with the app.config file, that you want to store in an .INI file or the registry, that you just want to store a single preference.... Or, in the case of CMAB, that you need a monolithic handler for something has simple as user preferences. Seems to me that with the framework's rich XML capabilities and the built-in support for the .config structure in System.Configuration, there'd be a clean way to go for basic preferences that formally went in the registry. I'm rolling up my sleeves on it at this point, but I'd be curious if others have also rolled their own, or if I'm missing something that's already out there.
ReplyDeleteI haven't come across anything yet. And after my experience with CMAB, I think I'm going to wind up writing my own. But of course there might be something out there that I'm unaware of.
ReplyDeleteUpdate on XmlSerializerSectionHandler - level 200
ReplyDeleteHere is another update to the XmlSerializerSectionHandler that Craig
ReplyDeleteAndera introduced. The code...