We are using Telerik Radcontrols for ASP.NET AJAX in a custom CMS-type application that will be used to host hundreds/thousands of client sites going forward. The application uses 4 or 5 Telerik controls and for each client we usually start with a standard Telerik control skin and then make some (potentially a LOT of) changes to it for that client. So far, we have been making a copy of the original skin, giving it a new name and making any changes directly to that copy but I am concerned that as time goes on, Telerik will release changes to the controls that also require changes to the standard skins (like you did in the 2009-Q2 release with radpanelbar) that will require me to go make tweaks to all existing customized client telerik skins in order to deploy a new DLL. This will get very scary as the number of clients scale up so I am wondering if you would recommend that instead of me making changes directly to a base Telerik skin we should instead use a base skin and then create a separate "custom" CSS file that over-rides any needed changes from the base skin using inheritance? The thinking is that then if Telerik comes out with new releases that have new versions of skins or modified skins we just plug those in place of the old ones we are using and the custom "over-ride" CSS file for each client continues to do it's thing (in theory). Is there anything inherently better about the original approach or problems with the proposed new approach that I am not seeing?
Thanks in advance for any help you can offer.
Thanks in advance for any help you can offer.
1 Answer, 1 is accepted
0
Hello Jeff,
I admit that we have made breaking changes in the RadControls rendering and skinning in the past few years. However, our controls are pretty mature with this regard now, so such changes will occur rarely from now on. Still, we cannot guarantee 100% backwards skinning compatibility in the future, that's why in a situation like yours with so many custom skins to support, I recommend you to be a little pessimistic, just in case. Don't get me wrong, we are not the bad guys, which always try to cause headaches to customers, but for your own peace of mind, I recommend you to:
+ use as many embedded skins as possible, without customizing them
+ make as few customizations as possible, the way that you have proposed - using an embedded skin, but overriding it with additional CSS styles. In this way, if we introduce a breaking change, the customizations may not work, but the embedded skin will, so fixing the customizations will not be that urgent and critical.
+ if you need to make really a LOT of customizations on a particular skin, then overriding the embedded one will not have any benefit, so it will be better to use only a custom one
+ reusing customizations and custom skins across sites and pages, if possible
+ it may be beneficial to use simple custom skins, i.e. with not too many background images or complex CSS selectors. In this way migrating CSS code manually will be easier, if you have to do that some time in the future
+ upgrade RadControls on some regular basis, so that you don't turn up with a lot of broken skins after 2-3 years
+ get familiar with the release notes and make some tests before upgrading. Test with beta releases and if it turns out that you have a problem, prepare yourself for the upgrade by reading documentation articles, implementing migration tools (we may provide ones as well), asking us for tips, etc.
Sincerely yours,
Dimo
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.
I admit that we have made breaking changes in the RadControls rendering and skinning in the past few years. However, our controls are pretty mature with this regard now, so such changes will occur rarely from now on. Still, we cannot guarantee 100% backwards skinning compatibility in the future, that's why in a situation like yours with so many custom skins to support, I recommend you to be a little pessimistic, just in case. Don't get me wrong, we are not the bad guys, which always try to cause headaches to customers, but for your own peace of mind, I recommend you to:
+ use as many embedded skins as possible, without customizing them
+ make as few customizations as possible, the way that you have proposed - using an embedded skin, but overriding it with additional CSS styles. In this way, if we introduce a breaking change, the customizations may not work, but the embedded skin will, so fixing the customizations will not be that urgent and critical.
+ if you need to make really a LOT of customizations on a particular skin, then overriding the embedded one will not have any benefit, so it will be better to use only a custom one
+ if you need a complete custom skin, then I recommend you to use the "Colorize" or "Shift colors" options of our Style Builder. In this way, in a worst case scenario, you will easily create the custom skin again, based on the new version of the respective embedded skin.
+ reusing customizations and custom skins across sites and pages, if possible
+ it may be beneficial to use simple custom skins, i.e. with not too many background images or complex CSS selectors. In this way migrating CSS code manually will be easier, if you have to do that some time in the future
+ upgrade RadControls on some regular basis, so that you don't turn up with a lot of broken skins after 2-3 years
+ get familiar with the release notes and make some tests before upgrading. Test with beta releases and if it turns out that you have a problem, prepare yourself for the upgrade by reading documentation articles, implementing migration tools (we may provide ones as well), asking us for tips, etc.
Sincerely yours,
Dimo
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.