A Shared Settings Store for BlogEngine.net

<< Using Images in the BlogEngine Comments | Generic Data Store >>

Feb 5

You might think that BlogEngine 1.3 was released yesterday, but It actually been a while and it looks like people like it and want more. New version is under constructions and part of it, that I'm responsible for, is a new shared storage model. The basic idea here is to be able to use Extension Manager as a storage provider for any type of extensions. Today, if you look at Extension Manager from the 10 thousand feet, it looks kind of like Russian Doll: you have manager itself, it has collection of extensions, extension has collection of settings and settings have collection of parameters.

At a little closer look, you can see how it all fit together: extension writer creates settings object, set values and uses Extension Manager to save settings. Later, when settings need to be used, you'll retrieve them from Extension Manager passing extension name as a parameter. Behind the scene, Extension Manager persists this object into XML file or database depending on the type of data provider you are using, caches it for fast access, provide you with convenient methods to manipulate settings etc.

This is pretty nice, would be even nicer if widgets (coming in BE 1.4) and customizable themes could use this facility as well. Potentially, any component that needs customization and persistent storage to save and get this customizable settings, should use this storage instead of re-inventing it's own wheel. Below is a very rough draft of what it will look like, definitely will be changed but basic idea most likely will not: Extension Manager will be modified to handle many more types of "extensions". It should not change how extensions use manager today, but rather add more functionality and let others use existing model.

As I work through this, I will share my thoughts and concerns as I did working on the first version of Extension Manager so together we will make it better and build stronger community along the road. Stay tuned!

Writing extensions for BlogEngine 1.4 (part 2) In the first part, we wrote simple extension that changes case in the post to lower. Let’s s...Using multiple settings in Extension Manager One of the limitations in the Extension Manager is that extension can handle only one settings o...Writing extensions for BlogEngine 1.4 (part 3) Lets say we want to write an extension to track user activities on our site. Blogger should be abl...

Comments

2/6/2008 5:53:31 PM #

Great post! I really like where you are going with this.

One of the things I like about the Extension Manager is that returns an ExtensionSettings instance that provides simple, easy to use methods for setting and getting of persistent data. I think this is an improvement over the use of an XMLDocument instance as an interface to data, because it requires that the extension or widget developers write their own code to parse and cycle through the XML document. It can be tedious code to write and, I believe, should be provider by the framework (or helper classes). So I hope this changes in the final version of the widget framework.

I do have one suggestion for the ExtensionSettings that another GetDataTable method is added which takes a “table name” parameter. That way it can support multiple sets of tubular data.

Out of curiosity, what direction are you going with how data is persisted to SQL Providers? Will data be passed to the Provider as an XML document to store? Or will it be up to the Provider to select the format (if not XML) to store the data? I see pros and cons either way, so I’m curious as to the direction of the team.

Keep up the good work!

Phil

Phil Garcia |

2/6/2008 11:26:40 PM #

I do have one suggestion for the ExtensionSettings that another GetDataTable method is added which takes a “table name” parameter. That way it can support multiple sets of tubular data.

I probably will go with "Section" object that will serve as a holder for ExtensionSettings, so you'll be able to have multiple settings per extension, tabular or single values at your choice.

Out of curiosity, what direction are you going with how data is persisted to SQL Providers? Will data be passed to the Provider as an XML document to store? Or will it be up to the Provider to select the format (if not XML) to store the data? I see pros and cons either way, so I’m curious as to the direction of the team.

If I can get away with it, I'd just add "ExtensionType" and "ExtensionID" fields to existing table, so that it would have minimum impact on SQL providers and be completely transparent for existing extensions (default type and ID). It should really be no difference between XML document and object serialized to XML at this level. At least, this is my hope ;)

rtur.net |

2/7/2008 3:08:40 AM #

I probably will go with "Section" object that will serve as a holder for ExtensionSettings, so you'll be able to have multiple settings per extension, tabular or single values at your choice.

I agree a "Section" object is a better idea than a table name. Good idea!

Phil Garcia |

2/8/2008 6:50:14 AM #

And every extension/widget will have a xml file dedicated? Now the extensions.xml file is shared ...

OFF TOPIC: and the proposed feature of nested comments? :-P

Cristiano |

2/8/2008 9:39:04 AM #

And every extension/widget will have a xml file dedicated? Now the extensions.xml file is shared ...
Not necessarily, although it is a possibility - just to unify things. Currently I tend to leave extensions.xml as it is so people don't have to convert extension settings to new format. Will see.
Nested comments would be nice, I agree. If some one come up with a patch... ;)

rtur.net |

2/13/2009 9:08:10 PM #