This project is read-only.
Oxite now includes some basic support for skinning (CSS + images, scripts and views).

A Default skin including only styles and scripts is provided that layers the style and behaviors on top of the default views.


The quickest way to create a new skin is to just make a copy of the Default folder in <OxiteSite>/Skins with your own skin name (in this case skewed).


To make the site use the new skin first log in then follow the manage site link in the admin menu.


Under the Manage Site section follow the Settings link to edit the site's settings and change the Skin Name field to the (folder) name of the new skin and submit the form.


Now* you're all set up with your own skin - that looks just like the default. Yay!
* with the current release you might need to restart your app for the change to be picked up by the skinning engine.


Or with a little tweaking, something a little different...


From there you can change all of the CSS and JavaScript you want (using the same selectors). You could even override one or two or ten or all of the views (including the master page) by adding a "Views" folder to your skin and following the same hierarchy drop in the new view.

For example you could copy header.ascx from <OxiteSite>/Views/Shared into <OxiteSite>/Skins/<your new skin>/Views/Shared


and change it up a bit to get an amazing new header


But what if you wanted the menu out of the header and stuck to the side of the content? Pull the menu markup out into it's own partial view and add a copy (from the default) of the master page


modify the master page for the skin to make use of the new menu partial view


and (along with a little change to the CSS) you end up with something like


Last edited Feb 16, 2009 at 11:31 PM by skewed, version 11


sanafartalar Feb 23, 2009 at 9:24 AM 

skewed Feb 17, 2009 at 7:46 PM 
Now that skinning is baked in a little better I can now say the plans around skinning master pages in my previous statement were all garbage :)

Master pages are specified in the aspx with the MasterPageFile attribute and a skinned master page of the specified name is applied if found so nothing special needs to be done for skinning master pages in the latest (Oxite.2009.2.15) release.

skewed Jan 9, 2009 at 3:54 AM 
As it stands right now, the master page name defaults to "Site" in the OxiteViewResult and there is no way to override that value from a view page.

I'm planning to add a MasterName property to BaseViewPage that could be added to the Page directive in a page to override the default master name coming up from the view result. This could let someone set the MasterName for a page to, say, "SpecialArea" and that page will get the skinned SpecialArea.Master instead of Site.Master by default.

Until that's done, the MasterLocation attribute (from System.Web.Mvc.ViewPage) can be used instead of MasterPageFile to set the path directly to another master page (e.g. MasterLocation="~/Views/Shared/SpecialArea.Master").

jarrettv Jan 7, 2009 at 7:02 AM 
Thanks for updating the links. Sorry for the confusion on the MasterPage. I'm trying to understand how the view engine picks a master page when the MasterPageFile attribute has been removed from all the content pages.

skewed Jan 6, 2009 at 9:33 PM 
Yep. If you drop in a "skinned" master page it'll be picked up (just added the info to this page).

Duncanma Jan 6, 2009 at 7:36 PM 
as far as I know we allow the override of the master page as well, but as to the rest of your comments... this isn't intended as a per area (blog) skinning system, which is definitely a cool feature. If we were to implement that, it would likely end up as additional information stored along with the area in the database (a theme choice or custom css). This is currently focused on the scenario that I might want a different site wide skin than Nathan would like, or than might be suitable for

We haven't focused on multi-tenant features yet (skinning would be just one part, there would be a lot of additional provisioning admin UI required for example), I'm glad to hear your engine has... as you may have noticed, we added a link to it on our homepage as a blog engine option that uses ASP.NET MVC. There is a relatively large audience out there looking at CMS and Blog projects, so it is great to have multiple projects with different focuses and feature sets.

jarrettv Jan 6, 2009 at 6:27 PM 
It doesn't look like you can skin each area individually as the skin applies to every blog on the site. I suggest you take a look at the source code of BlogService to see how we support different themes at the workspace (site), and collection (area) levels. Also, the theme view engine can resolve the MasterPage correctly if the theme has one different from the default theme.