So I had my infrastructure in place for allowing plugins on this blog, now I wanted to add some sort of storage mechanism for those controls.
My first thought was they could just connect to the database and add tables themselves, but there were a few things I didn't like about that.
- I wanted the blog site to just grab the plugin and be able to immediately use it. However that would require allowing the control to add tables to the database. Which means I'm writing code that uses a connection with db admin level permissions. I didn't like that at all. Now maybe if I had a separate database for plugins this could be an option, but still a poor one, but a separate database wasn't an option anyway. So for security purposes if the plugins wanted to add data access they would need to do a separate step to run a db script. Pfft.
- I also didn't like that granting the plugins data access would potentially allow them to manipulate the core blog data as well. Maybe this is paranoid of me, but if I could figure out a way to avoid this as an issue then I was all for it.
So what to do? I wanted plugins do define their own configuration rules. I didn't want to limit what they could store, but I still wanted to provide a single common solution.
Ok, so my first thought was just some sort of name/value pair collection that plugins could use. It would work, it wasn't exactly elegant or very flexible, but it would work. However before I even got started I got a better idea. Why not use XML.
How about a table that could store configuration information for each plugin as xml. All the table would need was a relationship to the plugin, and a field to store the XML. If I stored it as actual XML then I could even use xpath to facilitate my queries.
Hmm this had promise..
I started to implement this and ran into something I didn't like. Namely storing the actual configuration as XML in the database. I'm using LINQ to for my data access, and that parses the database xml into System.Xml.LINQ structures instead of System.Xml structures. The LINQ Xml structures weren't letting me do a few things I wanted to use, that the System.XMl structures allowed. Essentially they weren't playing nice with Serialization To and from objects, so I had to take the LINQ Xml objects and do a conversion to make them System.Xml objects
Wait a second if I have to do a conversion then why bother storing it as XML? Yes I could use XPath queries in the database, but honestly was that really neccessary? Considering there probably not going to be a lot of plugins, and each plugin is probably only going to have a small amount of configuration data why bother? So I vnverted my XML in the database to a text field and just loaded it up into an XmlDocument, then parsed it that way.
Its clean to use, its flexible for the plugins, and its simple to use. All in all I like it so far.