Nathan Heberley
Top achievements
Rank 2
Rank 2
Nathan Heberley
asked on 11 Jan 2008, 04:42 AM
I have been using Telerik controls for some time now and I feel the decision to imbed the control skins into the prometheus suite seems a ridiculous step backwards.
Our web based products allow the users to select aTheme which best suits thier taste and their selection is programmatically implemented.
With the New prometheus suite it is basically a pain in the A** to implement this mechanism for the fact that to make an alteration to one of the control skins (which happens reguarly) we then have to manually register this new/altered skin in the page (so we have to programatically change this link to fit the required skin as well)....... Aren't themes suppose to remove this requirement?
We are currently thinking about ignoring Prometheus (which is a shame because I'm sure there are performance bonuses to be gained) because apart from the schedular everything else can be achieved using the old ASP.Net controls with alot less annoyance (from failed installs through to actual use).
Is this just a temporary issue with the custom skin situation and if so when would you expect it to be corrected ?
Our web based products allow the users to select aTheme which best suits thier taste and their selection is programmatically implemented.
With the New prometheus suite it is basically a pain in the A** to implement this mechanism for the fact that to make an alteration to one of the control skins (which happens reguarly) we then have to manually register this new/altered skin in the page (so we have to programatically change this link to fit the required skin as well)....... Aren't themes suppose to remove this requirement?
We are currently thinking about ignoring Prometheus (which is a shame because I'm sure there are performance bonuses to be gained) because apart from the schedular everything else can be achieved using the old ASP.Net controls with alot less annoyance (from failed installs through to actual use).
Is this just a temporary issue with the custom skin situation and if so when would you expect it to be corrected ?
4 Answers, 1 is accepted
0
Hi Nathan,
Thank you for the feedback.
The current skins implementation in RadControls "Prometheus" is very easy for users (you do not need to deploy an additional RadControls folder containing external scripts and skins) -- you only need a single DLL in your application without any external resources. For the majority of our customers this is a really simple approach.
The skinning mechanism is yet powerful and flexible for all guys like you who want to create custom skins (and change them dynamically). Please note that you do not necessarily need to register your custom skin in the page itself. You can choose to use ASP.NET themes and register your CSS files through the theming mechanism of the framework (and dynamically change the theme for the current user). Have you tried the approach we have described in this help article: http://www.telerik.com/help/radcontrols/prometheus/?ThemesHowTo.html? (actually all topics in http://www.telerik.com/help/radcontrols/prometheus/ RadControls "Prometheus" Fundamentals -> Controlling Visual Appearance contain important skinning information)
So far we have only received positive feedback on the new skinning mechanism and will be happy to hear more input. Is the new mechanism usable for you? Does it simplify deployment for your apps? Do you feel that the custom skin registration (on the page or through ASP.NET Themes) works OK for you? Does anybody else think the "Classic" RadControls approach was better (and why)?
All the best,
Ivo
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center
Thank you for the feedback.
The current skins implementation in RadControls "Prometheus" is very easy for users (you do not need to deploy an additional RadControls folder containing external scripts and skins) -- you only need a single DLL in your application without any external resources. For the majority of our customers this is a really simple approach.
The skinning mechanism is yet powerful and flexible for all guys like you who want to create custom skins (and change them dynamically). Please note that you do not necessarily need to register your custom skin in the page itself. You can choose to use ASP.NET themes and register your CSS files through the theming mechanism of the framework (and dynamically change the theme for the current user). Have you tried the approach we have described in this help article: http://www.telerik.com/help/radcontrols/prometheus/?ThemesHowTo.html? (actually all topics in http://www.telerik.com/help/radcontrols/prometheus/ RadControls "Prometheus" Fundamentals -> Controlling Visual Appearance contain important skinning information)
So far we have only received positive feedback on the new skinning mechanism and will be happy to hear more input. Is the new mechanism usable for you? Does it simplify deployment for your apps? Do you feel that the custom skin registration (on the page or through ASP.NET Themes) works OK for you? Does anybody else think the "Classic" RadControls approach was better (and why)?
All the best,
Ivo
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center
0
Nathan Heberley
Top achievements
Rank 2
Rank 2
answered on 12 Jan 2008, 01:56 PM
Good Evening Ivo
I must admit that from your post above I seem to have missed how the skinning mechanism works. My team and I were under the impression (from the articles about prometheus & the online documentation) that we had to register the customised skin in the page in which the control was being used.
I put this down to the fact that prometheus was in beta and would be improved at a later date. Such as what happened with some controls when RADAjax was first introduced where the controls skin had to be registered with the page manually for it to work correctly after a call back.
I will look over the articles you sent through and have a chat to the guys on monday and see what can be done.
Thanks
I must admit that from your post above I seem to have missed how the skinning mechanism works. My team and I were under the impression (from the articles about prometheus & the online documentation) that we had to register the customised skin in the page in which the control was being used.
I put this down to the fact that prometheus was in beta and would be improved at a later date. Such as what happened with some controls when RADAjax was first introduced where the controls skin had to be registered with the page manually for it to work correctly after a call back.
I will look over the articles you sent through and have a chat to the guys on monday and see what can be done.
Thanks
0
greenmodulus
Top achievements
Rank 1
Rank 1
answered on 08 Mar 2008, 08:53 PM
This would be fine if the images would show up. As far as I can tell, I followed all of the steps in the documentation.
I copied the WebBlue folder into my App_Themes\UserAdmin folder. UserAdmin is the theme we are using.
I set the EnableEmbeddedSkins="false".
In the WebBlue folder I copied the Entire Calendar and Input folder as well as the Calendar.WebBlue.css and Input.WebBlue.css files.
This clearly is now using the Theme folders WebBlue and not the embedded one because all the images don't show up.
When I view the source, it says src="fastNavLeft.gif" with no path so of course it won't find it in the App_Themes\UserAdmin\WebBlue\Calendar folder.
This worked before in Q3 release and is broken in Prometheus. Something changed that is not making this work.
I copied the WebBlue folder into my App_Themes\UserAdmin folder. UserAdmin is the theme we are using.
I set the EnableEmbeddedSkins="false".
In the WebBlue folder I copied the Entire Calendar and Input folder as well as the Calendar.WebBlue.css and Input.WebBlue.css files.
This clearly is now using the Theme folders WebBlue and not the embedded one because all the images don't show up.
When I view the source, it says src="fastNavLeft.gif" with no path so of course it won't find it in the App_Themes\UserAdmin\WebBlue\Calendar folder.
This worked before in Q3 release and is broken in Prometheus. Something changed that is not making this work.
0
Hi greenmodulus,
The described behavior seems to be rather strange, as you are using the correct mechanism for applying Themes in Prometheus suite. Will it be convenient for you to open a regular support ticket and provide us with a sample project, including the custom css file, which replicates the presented issue.
We will test it locally and advise you further.
Regards,
Maria Ilieva
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center
The described behavior seems to be rather strange, as you are using the correct mechanism for applying Themes in Prometheus suite. Will it be convenient for you to open a regular support ticket and provide us with a sample project, including the custom css file, which replicates the presented issue.
We will test it locally and advise you further.
Regards,
Maria Ilieva
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center