CODEWITHSUNDEEP
asp.net-mvc-3
sandy
sandy

Reputation: 11

dynamic theme in MVC3

I have been working on a MVC3 new project where I wanted to introduce the concepts of dynamic themes.

Instead of creating a bunch of .css files and dynamically linking to the right one, I wanted to use a <style> section in master <head> section that specifies the values to use for the selectors and their properties.

The values would be pulled from a database and written to header section in style, look like this:

<head>

<style type="text/css">
.testClass { color:Purple;background-color:LightGreen; }
</style>

</head>

Upvotes: 1

Views: 4045

Answers (1)

Kent McNeill
Kent McNeill

Reputation: 361

Not an answer on how to achieve this end, per se, as much as a suggestion that you reconsider. I have seen this approach taken firsthand several times over the years, and it invariably ends up first with writing a proprietary tool to edit the database themes and subsequently with an expensive rewrite to extract all the themes out of the database and into proper css files.

One typical reason to go down the path of putting styles in the database tends to be a desire to allow a given style to be "overridden" on a case-by-case basis - for instance, in an application service provider model, where one customer wants to change only one or two of the default styles. However, the "cascading" in "cascading style sheets" allows this exact behavior, without abandoning all the goodness of proper css and the associated tools - as long as you sequence the stylesheets in the correct order in the page head (e.g. "maintheme.css" first, then "customerX.css"), you only need to redefine the styles of interest in the customer's stylesheet and they will automatically override those in the main theme's stylesheet (assuming the css selectors otherwise have the same precedence).

A related, but slightly different reason given for going with database-driven stylesheets is to allow end users or business owners to edit the styles themselves. With a few exceptions, that sort of feature turns out to be less used and more difficult to maintain in practice than it seems when drawing it up. In this case, the number of styles being customized is theoretically quite small - presumably entirely constrained - and you'd be writing a proprietary tool to allow them to be edited, regardless, so again I would suggest simply writing out the customized styles to a css file on a filesystem, rather than a database (or as a blob to a CDN, etc.).

Upvotes: 1

Related Questions