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!

Signature

Related posts

Comments

2/6/2008 9:53:31 AM

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 3: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/6/2008 7:08:40 PM

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/7/2008 10:50:14 PM

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 1: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

Add comment


 

  Country flag

biuquoteimg
Loading



<<  July 2008  >>
SuMoTuWeThFrSa
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789
Enhanced with Snapshots

Subscribe to Rtur.net