This project is read-only.

Themes, Skins, Styles

Sep 16, 2008 at 9:24 PM
Edited Sep 26, 2008 at 9:01 PM
Here are my thoughts on themes.  The majority of themes should fit in the "css + images only" by utilizing a CSS Zen Garden style markup.  I've already updated most of the markup to be Zen-like.  My hope is to make theme's easier to create and maintain.  However, power users can modify master, aspx, and ascx files for even more control.

Therefore, a simple theme will just be a style sheet and any images referenced by the stylesheet.  A complex theme would be similar to how is doing it <STRIKE>but without the built in support for dynamically changing the master and ascx controls</STRIKE> but simplified via MVC.  I guess it would be closer to how wordpress users replace their php files.

When there are multiple workspaces in a single instance, I'm ok with the limitation that all workspaces must use the same master, aspx, ascx files. Update: this is no longer a limitation with the move to MVC.  However, themes can be set at the workspace level and overridden at the collection level by setting the theme name in the service document.  For example:

<workspace theme="blue">
 <collection href="blog.atom">
 <collection href="media.atom">
 <collection href="photolog.atom" theme="fotoman">

  • Simple to create new themes
  • Themes are more likely to be forward & backward compatible
  • Less logic to implement
  • Easier to deploy and configure
  • Promotes good markup standards (like CSS Zen Garden)
  • Should allow for greater variety of themes out of the box
  • Easier support of alternate styles (print, mobile)
  • Markup must be standardized with appropriate id's and classes
  • <STRIKE>Markup can't change dynamically based on theme</STRIKE>

Sep 16, 2008 at 9:24 PM
Edited Sep 18, 2008 at 5:34 AM
Tasks to support CSS + Images

  • Detect workspace - Done
  • Add theme setting to both workspaces and collections - Done
  • Allow collection theme setting to override workspace theme - Done
  • Set stylesheet based on theme setting - Done
  • Create theme repository like
  • Create admin page that can auto-download and apply themes from repository

Sep 16, 2008 at 9:54 PM
Why not use theme & skin support built into ASP.NET?

  1. Read
  2. The above site also has many posts on workarounds and fixes that I'm not interested in having to do.
  3. Future move to MVC...

Sep 17, 2008 at 2:40 AM
Agree that "css + images only" is the way to go... as the article above points out - ASP.Net skin support won't allow you to control the order of styles, and therefore 'cascade' or override id or class selectors in the correct order.

Also agree with the move to a controller/view engine approach in vNext. Have had some good experience with the NVelocity view engine...(currently maintained at There's a little more code required behind the scenes in order to support a completely seperate view/templating engine - but in exchange the user gets a very flexible templating language as well as complete control over layout and style [of course the Webform view engine in ASP.Net MVC may be fine as well].
Sep 17, 2008 at 6:25 AM
Thanks for posting that link. I looked into nvelocity last time you mentioned it and when found the site, I thought: why the hell would anyone want to use an old and abandoned project?

Castle nvelocity intrigues me because I used to love building websites using XSLT.  However, I'm hoping the webform view engine in mvc will be sufficient.
Sep 17, 2008 at 8:44 AM
Edited Sep 17, 2008 at 8:47 AM
Very similar to the idea of creating an XSLT transform (although XSLT is a transform view, whereas NVelocity is a template view - details, details... lol)

There has been a lot of renewed interest in NVelocity since ASP.Net MVC was announced. Castle have used it for many years, and have also maintained it.

I used NVelocity to create my gallery templates at, and the folks at Telligent (with Scott Watermasysk from the original .Text blogging engine) have used it in Graffiti - their new lightweight CMS/Blogging application - In Graffiti they are calling it the 'Chalk' templating engine. If you download the Graffiti application - you'll see the NVelocity.dll in the bin directory - and you'll also see how the templates are managed - take a look in one of the themes directory like ..\Graffiti\Web\files\themes\Skittlish.

If I have time I'll create a FooVelocity sample app and send it along. The advantages of using NVelocity are that you get a well documented, full featured templating engine out of the box. Users will quickly 'get' how they can adapt or change their templates as long as we publish a list of available 'tags'.

The downside is that there's a little bit more plumbing required on the application side in order to prepare the html, or values for tag replacement in the templates.

Of course if the view engine is properly abstracted in the application- then in theory, switching between one view engine or another shouldn't be that difficult.

The templating/macro approach is also the approach used in dasBlog  - again making changes to templates and themes is very easy. I need to take another look at - although if I remember correctly this was also a pretty cool templated view approach. Not 100% yet either how this would compare to the Webform view engine in ASP.Net MVC - or which would be more work to implement...or what the trade offs are. Will be interesting to compare though...

Sep 18, 2008 at 5:20 AM
With MVC, it should allow for flexibility to choose from multiple view engines. However, we need to decide on the default view engine and push for as many themes as possible on this view engine.$0$0$0$0Can you list the pro and cons of going with nVelocity?$0
Sep 18, 2008 at 4:54 PM
That's a good point. At first blush I think for non-techy people creating themes using the NVelocity templates are easier. For power users, you can do fancy stuff too -  like iterations, fancy loops, zebra stripes etc.  Also a theme that's already been created in this style (say for Graffiti) would be easy to bring over.

But as with everything - the devil is in the detail. I think we need to prototype both on a couple of test pages. I'd be glad to put together an NVelicoty test app for us to experiment with.... and then see what we all think...

I'm away now until Sunday pm at this end. So if I do anything with this it will have to be early next week.

Later :-)
Sep 19, 2008 at 10:30 PM
Created a new blog post detailing the theme scenario for a non-techy person (thanks to my wife).
Sep 20, 2008 at 11:27 AM
Nice. The new blue theme on your own site is pretty good too! :-)
Sep 24, 2008 at 11:31 AM
Edited Sep 24, 2008 at 11:32 AM
Another thought that occurred to me where site themes go... is that it might be useful to have a theme.manifest xml document located in the theme directory.  If nothing else the manifest file could tell the application which view engine the theme was created for (assuming there is more than one :-) - with the controller passing off to the correct viewengine accordingly.

Again not close enough to it yet to know for sure... but do you think we'll have some common bits? Like and Admin view using the Webforms view engine for site management etc... and then theme directories separate  from that for the user customizable part of the site?
Sep 26, 2008 at 8:50 PM
After making progress with MVC, it totally opens the door to having dynamic replacement of markup pages based on themes.  I think we will still push for CSS only themes, but with MVC there is tons of flexibility.
Oct 8, 2008 at 10:50 PM
I've reorganized themes slightly under MVC:

/themes <-- aka Views folder contains all themes
/themes/default  <-- special default theme folder that all themes fall back on
/themes/default/images <-- standard images folder

Each theme folder contains the stylesheet css file and any aspx or ascx files that will override the default theme.  The master page Site.master file is special in that if it exists for the theme then it applies to all pages, even pages which have not been overidden (default pages).

Therefore, a theme can be as small as a css file (and images) or any and all views (aspx and ascx files) to completely override the default theme.