Video - widget framework

Jan 6, 2008

During this weekend I finally had some time to start working on the next version of BlogEngine.NET after a long break over Christmas and new years. In particular the widget framework, which is something I've really looked forward to building. This is something Al Nyveldt and I had discussed for the last 6 months or so and quietly conceptualized during that period. I finally took the plunge and started writing the proof-of-concept code for this widget framework.

Some of you who have followed the roadmap might have wondered what a widget framework is; at least no one has commented on it yet. To make this as simple as possible, I've recorded a video of this new code.

Watch widget framework video

The purpose of getting this video out, is that I would really like some feedback as early in the development process as possible. So, if you have anything to add after watching the video, please do so. You can get the next version of BlogEngine.NET in any super market later this spring.

* $4.95/month BlogEngine.net Hosting – Click Here!

Creating widgets for BlogEngine.NET 1.4A tutorial on writing widgets for BlogEngine.NET 1.4Twitter widget exampleGet a Twitter widget for BlogEngine.NET 1.4Dangers of the new ASP.NET MVC frameworkWill the MVC framework divide developers and create a dual ASP.NET community?

Comments (19) -

Phil Garcia

1/6/2008 7:44:00 PM #

Very Cool! This will be a great addition to BE! I was wondering, will the CSS be selectable by widget, or will this be primarily driven by the theme's CSS?

For persistent storage for widgets, you might want to take a peak over at the Photo Gallery extension project. We have been experimenting with an extendable data layer. One of the benefits to this approach is that extensions can implement their own provider components (if one is not available) under the provider. No need to expand the BlogServer interface, or add anything to the BlogEngine.Core when you want to add an extension. In fact, the Extension Manager was itself modified to use this new data later. It and now supports SQL, in addition to XML.

Mads Kristensen

1/6/2008 7:52:31 PM #

The data storage is just proof-of-concept and I'm very interested in seeing what you guys have come up with for the gallery. The thing that makes an XmlDocument class great for data storage is that you have total freedom to write all types of things with no limitations. The base class used in this video takes care of fetching and saving the XmlDocument for each widget and therefore also controls where to store it. The point is to let the provider model handle the fetching and saving of the XML, so it can either go in a database or XML files. Either way, the data type will be of XmlDocument.

Now, remember this is just proof-of-concept and is most likely to change, but I must admit I like the XmlDocument approach since it gives total control to the widget authors.

Mads Kristensen

1/6/2008 8:07:49 PM #

Regarding the CSS, then it is very much controlled by the widget itself. The widgets should be so loosly coupled as possible so you do pretty much whatever you want. However, some things like the headline are controlled by the themes to make them blend more into the overall design of the themes. In that regard you can say that theme designers as well as widget authors will get a huge amount of control over the look and feel of widgets.

Luke Foust

1/6/2008 8:22:27 PM #

I really like the simplicity of your design. I agree that these widgets must be easy to write for developers.

One concern I have has to do with deployment. I think being able to wrap a widget in an assembly would be much easier to share/deploy than having to distribute a folder with some user controls inside of it. Have you thought about how these widgets with be shared/deployed?

Also, I am not too sure about using the XmlDocument as the main data storage mechanism. I think it would be better to abstract away the needed functionality (storing and retrieving values, etc) in case you need some functionality in the future that the XmlDocument can't provide.

Keep up the great work.

Phil Garcia

1/6/2008 8:26:11 PM #

I agree. In our experiment, the Extension Manager settings are persisted as an XML document in either the local file system or in SQL. It's way too much work to normalize a tree-like data structure (like XML) to a normalized table/data/row structure in an SQL database, where the only perceivable benefit to doing this is you can now make edits using SQL tools or commands. I don't know why post/pages/etc were not stored in SQL as an XML document in the first place. I wish it was; it would simplify the entire data layer.

I do have this question for the BE team, when you being to support multiple blogs from a single BE instance, are you going to continue to keep everything in memory (which may not be impractical due to memory requirements), or will you change the business layer to query the data from a database as necessary?

Mads Kristensen

1/6/2008 8:42:50 PM #

@Luke,

The deployment and development is much simpler with the use of folder that you just drop into the widget folder - much like the way you do with extensions today. Deploying ddl's doesn't let people modify the widgets and hides how it does things. That way people can much more easily learn how to write widgets by looking at other peoples code.

As for the XmlDocument as data storage, it actually does abstract the fetching and saving away from the widget authors. A Widget just have a property inherited from the base class called Xml. You don't have to worry where it came from and where it will be saved to.

@Phil,

BE will be a multiblog platform some day. Maybe not for the 1.4 release but maybe for 1.5 or 1.6. There is just so many things that we want to do before that. I have thought of making it a provider based concern whether or not to support multiple blogs. That will at the same time push more responsibility to the providers including caching of posts. That way you can have a SQL provider that doesn't cache posts in memory like it does at the moment. It will be needed if it has to run multiple blogs. Another benefit is that you can choose a single blog provider if you don't want to bother with the extra complexity a multiblog scenario brings.

Ronny Engelmann

1/7/2008 5:46:15 AM #

In the next weeks i will relaunch my website with BogEngine.NET. I like your work and will develop some widgets

Hartvig

1/7/2008 8:33:36 AM #

This is so simple that it proves it's done right. Great job, and very inspirering for me to use videos as proof of concepts.

(why the f*** haven't you been giving an MVP)

Sam MacDonald

1/7/2008 9:03:11 AM #

I've downloaded the code from codeplex to take a look at. It's nice clean code what i've looked at so far and fits the bill on some of what i've been looking for functionality within BE. Will be playing with the code further on today.

Danny Douglass

1/7/2008 4:06:56 PM #

Nice concept! I'm really looking forward to this widget framework. I'm working on a resource center (links/downloads) extension that I would like to provide a widget to allow listing your latest links on all of your pages.

Keep up the good work Mads & Team.

Rafiq

1/7/2008 9:04:04 PM #

I am eagerly expect to see it!

Amr

1/8/2008 8:34:33 AM #

This will be very useful, the thing I just needed can't wait for the release.

Chris Pietschmann

1/9/2008 6:48:21 PM #

It looks awesome, I can't wait to see the final implementation.

By the way, I'm not using BlogEngine.NET for my blog yet (still using the code I wrote 2 years ago), but I am thinking about migrating over to it soon. Keep up the work.

Luke Foust

1/9/2008 8:34:14 PM #

@Mads,

Regarding the XmlDocument - I understand that it is an abstraction but I was just advocating that you use your own class (which you have complete control over) rather than XmlDocument (which is owned by the authors of the .Net framework). I definitely agree with the idea that the widget author should not have to worry at all about where their settings are being stored.

Mike Hamilton

1/11/2008 2:03:56 PM #

Looks good so far. I agree the settings should be more abstracted away. instead of exposing an XML document I would expose a custom Settings object to the widget creator. That Settings object should have methods to set a setting.

ie
base.Settings.Set("content", "sometext")

and this would do the check for a node in the xml document and add it if needed and then set it. And a matching getter.

content = base.Settings.Get("content", "default value")

Just my thoughts.

Chris

1/13/2008 12:39:52 PM #

Mads-

I am not much of a developer, just a user. Although not difficult to comment out code for 'widgets' currently, I very much do like the proof of concept. This is DEFINITELY something that well help the non-code savvy users adopt BlogEngine.NET.

Thanks very much for all your, and the teams, hard work. Keep it up!!!

tanvon malik

1/27/2008 9:39:46 AM #

Hi
    a big step in a short time. This was the only thing I was missing in the BlogEngine.NET, because after that framework, now it will be easy to modify the sidebars, and a new way for the developersto create the things. after this it will also be easy for the users to change the look and adding thins they like without changing a bit of code.
                Will this framework be completely hidden till its release, or you are planning to show it before its release, so we can get some idea how it actually be implemented, and we get ready.
                      thanks a lot

Phil Garcia

2/1/2008 4:29:02 AM #

@Mads,

Using your new widget framework, I created a configurable Stock Quotes Widget. You can download it from:

www.thinkedge.com/.../...-Widget-Stock-Quotes.aspx

After putting together this widget, I agree with @Mike and @Chris that the XmlDocument should be abstracted away (or replaced) with a custom Settings class. That way the widget code does not have to deal with extracting data out the XmlDocument. The code would seem cleaner too.

Keep up the good work!

Peter Provost

7/6/2008 10:30:44 PM #

Nice work. Having just ported my blog over to 1.3, I see I still have some work to do to get to the new 1.4 widget framework, although fortunately my theme works in 1.4 as is.

One thing that would be very nice for you and/or Al to do is to create a rough guide for migrating Themes and Controls over to the new framework.

Nice work!

Pingbacks and trackbacks (7)+

Comments are closed

Video - widget framework

Related posts

Comments (19) -

Pingbacks and trackbacks (7)+

About the author

Twitter

Month List

Disclaimer