After giving it more thought, I decided to make some significant changes to the picture from the previous post. Main reason is that I wanted to make settings layer a thing on its own. Make it more generic and flexible.

With this new approach, extension would be shielded from any changes by manager, while widgets, themes etc. can go straight to the DataStore object and get/save settings there. From the beginning, it would handle common data types like XMLDocument, Dictionary, ExtensionSettings and can be extended to use any data type in the future. Data providers will be responsible for saving and retrieving objects from the XML or database. Client code would look something like:

XMLDocument settings = new XMLDocumnet();
// build document
DataStore.Save(“MyWidget”, settings);
 
XMLDocument settings = DataStore.GetSettings(“MyWidget”);

Or even cooler:

grid.DataSource = DataStore.GetSettings(“MyTable”);

I will code proof of concept this weekend. Obviously, this is not enough to keep me occupied – alongside with this endeavor I started another one – transforming mp3player into a full blown podcasting extension. Not sure where it will bring me, one thing guaranteed – I’m not going to be bored to death any time soon ;)

Share/Save/Bookmark
Signature

Comments

2/8/2008 11:12:20 PM #

Phil Garcia

Looking good. You could replace "XML" with "File System". One provider that I would eventually like to write is one that uses Amazon S3 for persistent storage.

Phil Garcia |

2/10/2008 7:09:47 PM #

Matt Ellis

Dude, have you checked out the .net 2.0 Settings API? The default provider is an xml file based one, provided by the Configuration API (i.e. web.config), but you can implement and swap in your own providers via config. Might save you a lot of bother...

Cheers
Matt

Matt Ellis |

2/11/2008 12:50:26 AM #

rtur.net

Dude, have you checked out the .net 2.0 Settings API?

Not sure what Settings API is. Configuration API is not exactly what I'm looking for - if it all will come down to storing simple key/value pares (it might) then we already have reusable code that does it, including XML and SQL providers. I'm more interested in storing complex data types, including custom objects.

rtur.net |

2/11/2008 4:17:37 AM #

Matt Ellis

The settings API is (kind of) a superset of the config API. So you get to define complex types, and attribute them, in the same way you do with config, but it doesn't live in the web.config file.

Hmmm. Looking at it now, it might be that it's too desktop focussed. Could still be interesting to have a quick look at.

http://blogs.msdn.com/rprabhu/articles/433979.aspx

Cheers
Matt

Matt Ellis |

2/11/2008 9:27:20 AM #

rtur.net

That is very interesting, thanks a lot for a tip Matt.

rtur.net |

2/12/2008 8:47:45 AM #

John Dyer

Is there a way to store both scalar and tabular data in an extension? Right now I need a few "settings" and then some data points, but it seems the only way to do this is to create two Extensions, one for scalar and one for tabular, and then allow the user to edit the two separately.

John Dyer |

2/12/2008 9:26:04 AM #

rtur.net

Is there a way to store both scalar and tabular data in an extension? Right now I need a few "settings" and then some data points, but it seems the only way to do this is to create two Extensions, one for scalar and one for tabular, and then allow the user to edit the two separately.
Not yet - it will be in BE 1.4

rtur.net |

Comments are closed