A Better Skin System? - An Open Thought

[Tim Barton]

I  have been using Terlerik for many many years now and it is pretty much the only product design system I used to release my products. But for some time now I noticed that with each major Q release the Skins layouts seems to change drastically from previous builds causing site redesign. 

The latest Q1 2009 build seems to really change the skin layout for the controls I used even though I use my own modified skins from Q3 2008.  I think there needs to be a better way to upgrade to the latest builds without having to keep changing skin layouts.  That way, you still can get the latest technology Telerik releases and only optionally change your Skin.

One suggestion I would recommend is to use the Skins folder to store old skins in its build directory.  For example
 
Skins\Q320081125\...
Skins\Q12009311\...

That way, if you wanted to change to previous or future skins, you have that option.

I don't know if this is affecting others but it is becoming a nightmare for me when I spend a lot of time redesigning the presentation layer for every release.

Thanks,
Tim

[Peter Zolja]

I agree with you on the pain of upgrading the skins, but I don't see how your solution could work. The code that the assemblies generate is tied to the skins they use. For something like this to work Telerik would have to break / separate the code that outputs the HTML, which eventually uses the CSS skins, from the rest of the code. This would require a lot of work on Telerik's part and would limit them in the future.

[Tim Barton]

Hi Peter,

Thank for your reply.  You have the option to not use the embedded skins by setting EnableEmbeddedSkins="False"    I do this now with many skins that have changed since Q3 2008.  Telerik still can embed all future releases as they do now but just give the option of using old skins by setting the the above property and point to the directory I wrote about before.

But Telerik is a very talented company, there is a better solution to the skin problem and I know they will come up with something.

Tim

[Peter Zolja]

Let me explain what I was trying to say. Let's say in Q3 the control renders something <ul class="RootCss"><li class="First" />... </ul>. All those class=xxxx attributes are generated by the Telerik control itself. The skin, i.e. the CSS files that are loaded assume that you have a RootCss class with a First class as a child. This works fine in Q3. Now let's say in Q1, the next version, they decide that they want to generate a different HTML, something like this <ul class="Control_RootCss"><li class="Control_First  Control_LI" />...</ul>. For some reason they decided to prefix each class with Control_ and change a few other things around. The old CSS skin you used for Q3 won't work with Q1 because the rendered HTML is different. For the old skin to work, Telerik would have to ship the code that rendered the old HTML and the new HTML so that you could switch between the two. This doable, but it would complicate things quite a bit. I guess they've weighted the costs, and it would cost them less to just upgrade your skins then to support multiple "skin engines." Can't say I blame them on this one.

[Tim Barton]

I understand your point but the bottom line is Telerik is a very talent company and they can make moving to new versions less painful when it comes to changing skins.  My approach was and example of what can be done.  I rather see a seperate skin engine you can deploy then always having to change a design everytime they release new Q versions. 

For example skinQ320081125.dll or skinQ12009311.dll 

[Dimo]

Hello Tim,

We understand your point of view very well. The Q1 2009 release broke a lot of custom skins, because the control's HTML rendering changed (CSS classes naming conventions mostly). However, in order to support multiple versions' CSS skins in this case, we would have to make RadControls render different output, based on some property. This will be a major overhead and will only lead to more confusion. We prefer to help people migrate their custom skins, rather than implementing some complicated logic for the rendering.

(Peter, thanks for participating in this forum thread and for the explanations)

All the best,
Dimo
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.

[KSBA Techie]

I agree with Tim.  This will be the second time I've had to modify

my custom style sheets, because they've all broken with a major release.

The previous minor upgrades were as simple as copying up the new dll,

now I have to spend a couple days modifying all the custom style

sheets I created to match up with this new release.

Very time consuming, and painful.  Since I just want everything to look

the same way it does now.

[PureCode]

Steven,

Telerik released a fairly simple, but working converter for the old style skins.

Find the downloadable version here.

There is also a somewhat more limited web based version here.

Hope that helps.

Regards,

Mike

[allenh]

the downloadable skin converter  blows up on the form decorator - is there a version of the converter that has been fixed  to handle these errors?

signed, still stuck in Q3-2008

[Martin]

Hello allenh,

We introduced new changes in the rendering of RadformDecorator since Q2, and that's why the converter does not convert the old skins properly. We will fix this once the changes and improvements in this particular control are final, and I believe that this will be soon.

All the best,
Martin Ivanov
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.