Multiple Style & Skin module

Coordinator
Sep 25, 2009 at 2:54 PM

Hi All,

I am starting to create a module for being able to define & assign different skins for the SUGWSK (Silverlight User Group website Starter Kit).

The main idea is that each User Group should be able to easily create the most opportune Skin that adapts to his UG image - Initially we plan to produce between two and four skins but at least there will be two.

The idea of these is to serve as starting templates so the UG can adapt any of this skins to its taste, creating this own style.

The main idea is that this will work out through configuration and the Skin will be identified by a resource control which will provide the styles and then some container usercontrols that we will plug-in instead of the basic ones.

Any suggestions on how to approach this goal? any  idea is very welcome!

 

Best,

Jose

Coordinator
Sep 25, 2009 at 3:22 PM

Hey Jose,

      Sounds great.  It would be nice to have at least one additional skin in the initial release and an easy way for folks to create skins.    Let me put some thoughts into it and reply later on today.

Developer
Sep 25, 2009 at 3:26 PM

I'll ditto on David's response here.

 

Let me give it a little thought and I'll come up w/ a mockup for another skin.  I think it would be advantagious to show the diversity of the system and to have something different enough to visually explain that point.

Coordinator
Sep 26, 2009 at 11:49 AM

If I can speak conceptually further, right now we have a small collection of User Controls (past events, current event, tweets, etc) that are used with the current layout.  There is no reason that these same controls can not be used with another Template.  If we have multiple skins, we can use these same controls on that skin.  My suggestion for the initial release would be to take the easy road and create seperate skins for the project that share these controls.   Although it is not optimal, this would allow us to release the project with layout options for the user to choose from.  Moving forward, we can support true skinning and, similar to theming in Silverlight, designers can submit new skins and users can add them to their UserGroup websites, much like the the Expression Blend Themes Gallery.  Who knows, maybe in the future we can get some Expression Blend love and have a future home for our themes in the Expression Blend Gallery.    On that note, perhaps one of the templates that we can create can support the existing themes from this gallery.  I will open up this question as a seperate thread.

 

http://gallery.expression.microsoft.com/en-us/site/search?f%5B0%5D.Type=RootCategory&f%5B0%5D.Value=themes

Coordinator
Oct 1, 2009 at 12:18 PM

I agree to the Keep it simple rule :) -  so David's proposal is the most simplest.

Let's say this: we have two kinds of user controls, Content Controls - which will only change in style for a concrete skin - and Container Controls - which manage layout, how it interacts with the user and the content contols and all - so, there are some things to do:

1. identify these controls by type (content & container).

2. Set up a skin system than enables to change the style and the container controls that it desires. It can be, for example, only the main container page and the rest is done with styles..

3. Prepare the Container controls for:

3.1.- Take their main functionality out - in a related class. We should only touch "the View", hopefully no viewmodel will need to be touched....  And most of them will ony be "views" not having to display any data -that is a role of the Content Controls.

3.2.- Being interchangeable - so I can change one control by other and everythink will have to keep working perfectly. Here we might need DI.

3.3.- Maybe, set up a "base container control" and the Skin container control will just inherit it and all its base behavior.

 

As Step one, I'll implement the style part and then, the Skin side...

Also, I am thinking, for having a clean project to put the main Skin functionalities in a separate project wich will be used from the main one.

 

Any suggestions on this? does this sounds good? please do not hesitate to correct me, there is always a "better implementation" ;)