I could not get this to work, much at all, in a master/content site. It had a mind of it's own...
Has it been fixed for release?
I am very interested to see this control.. it's development.. usage scenarios.
I'm thinking of a devloper/client admin "skin browser" UI..
If I may suggest- how about being able to apply skins by radcontrol; radgrid, radeditor, radcalendar,.. etc.
.. optional to targeting control IDs.
Thanks!
David
9 Answers, 1 is accepted
0
PureCode
Top achievements
Rank 2
Rank 2
answered on 06 Nov 2008, 10:03 PM
Well, it looks like they fixed SOME things from beta.
The issue I ran into with the SkinManager is that 'removing' the skin name from the control through the properties window, leaves a ' Skin="" ' in the control, which causes the SkinManager to NOT work, one has to remove ALL 'Skin=' entries from Telerik controls in order to get this to actually work.
While it works after 'fixing' all the controls manually (insert a lengthy essay/rant about 'Rapid Application Development' and fixing stuff manually here) there remains one HUGE issue.
Considering the control has a nice 'ViewState' property, which is enabled by default, it apparently does NOT remember the new skin. So, that requires us to literally 'remember' the newly selected skin in the view state by hand. I can live with that (although, insert yet another lengthy essay/rant about 'Rapid Application Development' here) were it not that you can NOT detect a skin changing, since the control does not throw a nice event when the skin chooser changes, not an issue with the current 'it posts back, whether you like it or not', but that it shouldn't do to begin with.
While the control (in this state) does make it easier to roll your own chooser, it is still not RAD in my book and definitely does not work correctly out of the box.
So, suggestions:
In the current state, this control is practically useless for our custom application framework, and while we do not use beta software (meaning that we never tested the Q3 beta), i had expected this control to remove our need for developing just such a control ourselves. I guess I better get one of my developers on that ASAP, since i don't expect Telerik to fix this any time soon, and we need this functionality.
After several thousand lines of code (read: quite a bit of time and as thus, money) to get your RadGrid to do what we needed it to do (it really is about time you made things like the filter row, status bar, footers, etc support templates across the board, since we had to code all that ourselves, not to mention custom grid items), I am seriously starting to wonder if we perhaps are using the wrong product suite. Just too many workarounds, too many bugs, WAY too much custom coding required, too many design flaws, lack of design to begin with (SkinManager being a prime example here), etc.
Regards,
Mike
The issue I ran into with the SkinManager is that 'removing' the skin name from the control through the properties window, leaves a ' Skin="" ' in the control, which causes the SkinManager to NOT work, one has to remove ALL 'Skin=' entries from Telerik controls in order to get this to actually work.
While it works after 'fixing' all the controls manually (insert a lengthy essay/rant about 'Rapid Application Development' and fixing stuff manually here) there remains one HUGE issue.
- In the SkinChooser, choose another skin, any skin, after a post back (weren't you guys supposed to FIX that?), the newly selected skin is there, nice.
- Navigate lovingly to another beautiful page in your application.
- Start pulling out the last few hairs on your head, because the skin chooser and as thus the SkinManager has lovingly reverted back to the original skin.
Considering the control has a nice 'ViewState' property, which is enabled by default, it apparently does NOT remember the new skin. So, that requires us to literally 'remember' the newly selected skin in the view state by hand. I can live with that (although, insert yet another lengthy essay/rant about 'Rapid Application Development' here) were it not that you can NOT detect a skin changing, since the control does not throw a nice event when the skin chooser changes, not an issue with the current 'it posts back, whether you like it or not', but that it shouldn't do to begin with.
While the control (in this state) does make it easier to roll your own chooser, it is still not RAD in my book and definitely does not work correctly out of the box.
So, suggestions:
- Make the SkinManager override ALL skin settings on ALL Telerik controls, unless they are specified in the target controls (which would be named totally wrong in that case). The SkinManager provides a global skin, so any 'local' skins should be overridden, unless stated otherwise, simple logic. Yet easier would be to add an extention property to all controls, "UseSkinManager" (defaulting to true, of course).
- Follow up on your promises made during beta and get rid of that damned postback.
- Separate the SkinManager and SkinChooser into two controls, then we can throw the SkinChooser where WE want it.
- REMEMBER the selected skin!!!
- Throw a 'SkinChanged' event when the SkinChooser changes.
- As with many 'manager' controls in the Telerik Suite, master/content page related things are, excuse my french, CRAP. Yet again the 'TargetControls' property is unable to detect content page controls and therefor forces the developer to MANUALLY (insert essay/rant about <the usual> here) code controls into the collection. Perhaps a 'SkinManagerProxy' control is needed? (And this point goes for ALL manager controls except for the Ajax one, since that DOES have a proxy, and the AjaxManager is still practically useless in a master/content page scenario even with that proxy).
In the current state, this control is practically useless for our custom application framework, and while we do not use beta software (meaning that we never tested the Q3 beta), i had expected this control to remove our need for developing just such a control ourselves. I guess I better get one of my developers on that ASAP, since i don't expect Telerik to fix this any time soon, and we need this functionality.
After several thousand lines of code (read: quite a bit of time and as thus, money) to get your RadGrid to do what we needed it to do (it really is about time you made things like the filter row, status bar, footers, etc support templates across the board, since we had to code all that ourselves, not to mention custom grid items), I am seriously starting to wonder if we perhaps are using the wrong product suite. Just too many workarounds, too many bugs, WAY too much custom coding required, too many design flaws, lack of design to begin with (SkinManager being a prime example here), etc.
Regards,
Mike
0
PureCode
Top achievements
Rank 2
Rank 2
answered on 06 Nov 2008, 10:04 PM
Btw, it is lovely how my 'avatar' no longer gets scaled and now appears half UNDER the text of my post.
Regards,
Mike
Regards,
Mike
0
Accepted
Hi Mike,
I'm sorry because of these problems with the skin manager. Here are some clarifications:
1) RadSkinManager is designed to work on page level (no matter Master or Content) and will override every RadControl skin if this skin is not set. When you change the skin this is saved in ViewState and it will be persisted automatically on subsequent post-backs. When you navigate to another page in your application and return back to the page with skin manager the page will be reloaded with GET request - no ViewState persistence here! If you want to save your skin across pages you can set Telerik.Skin key in the web.config file or use Session to set/restore the selected skin when needed.
2) You can turn off the skin chooser if you set ShowChooser to false (this is by default)
3) We will add SkinChanging/SkinChanged events and in the meantime you can find the chooser using the skin manager controls collection and use SelectedIndexChanged event to achieve this.
4) Currently controls selection for ControlID property in the TargetControls is limited to the current naming container. You can Use ApplySkin() method to apply the skin for any other control outside of the current INamindContainer.
To illustrate you all these I have attached small example!
Let me know if you have any questions.
Sincerely yours,
Vlad
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
I'm sorry because of these problems with the skin manager. Here are some clarifications:
1) RadSkinManager is designed to work on page level (no matter Master or Content) and will override every RadControl skin if this skin is not set. When you change the skin this is saved in ViewState and it will be persisted automatically on subsequent post-backs. When you navigate to another page in your application and return back to the page with skin manager the page will be reloaded with GET request - no ViewState persistence here! If you want to save your skin across pages you can set Telerik.Skin key in the web.config file or use Session to set/restore the selected skin when needed.
2) You can turn off the skin chooser if you set ShowChooser to false (this is by default)
3) We will add SkinChanging/SkinChanged events and in the meantime you can find the chooser using the skin manager controls collection and use SelectedIndexChanged event to achieve this.
4) Currently controls selection for ControlID property in the TargetControls is limited to the current naming container. You can Use ApplySkin() method to apply the skin for any other control outside of the current INamindContainer.
To illustrate you all these I have attached small example!
Let me know if you have any questions.
Sincerely yours,
Vlad
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
0
PureCode
Top achievements
Rank 2
Rank 2
answered on 08 Nov 2008, 01:03 AM
I think you didn't quite understand what i wrote in my post.
Apart from the issues, there is a fundamental design flaw with the SkinManager. It is simple, remove all skins (eg, set em to Default) from your page and they all look like 'Default', which is pretty much a giant eye-sore not to mention that it throws off any positioning entirely. the SkinManager may skin these things (if it remembers the skin that is, which i still say, it doesn't) but it only does so in run time.
Now, in our framework testing application, the main menu bar is WAAAAAAY too wide under the 'Default' skin, as opposed to, say, the Office 2007 skin where it is just over half the width of the page. So, the SkinManager completely and totally destroys ANY 'what you see is what you get'. The whole skin system is simply NOT made for such SkinManagers since the sizings differ enormously between skins, and it WILL destroy the look of an application if a skin is changed on the fly.
So, after sleeping on it, our conclusion as a company is that the new control is completely useless. Forget the 'reverse-designing' issue, forget about it seemingly not remembering the selected skin, throw it onto a fixed width site (like yours), change the skin and your page is totally ruined if the new skin has different sizes for the controls (RadMenu being the primary example), and i think most (if not all) skins have hugely differing sizes in them as compared to their counterparts.
This has actually been an issue for us for a while, even with just a single skin used. Take a RadComboBox (Office2007 skin), and plop it into, say, the pager of a RadGrid. The font size within the RadComboBox will become smaller due to the skin and location within the RadGrid, but the text in the RadComboBox (NOT the drop down (don't get me started on the drop down... MAJOR headache), the input itself, you know, the one that you cannot access from code-behind because it is created at run-time within a method that cannot be overridden) is now no longer centered vertically correctly and one needs to actually code some javascript to override the actual skin settings in order to get the alignment correct.
I think you guys need to re-evaluate your skinning system and actually make it work correctly before you can even think of a usable SkinManager. Better yet, start with a SkinManager and develop a skinning system around it. Refer to Infragistics for an example on how skins should work, even if theirs isn't (nearly) perfect either.
The whole skinning thing with the ridiculously complex CSS files has been our #2 issue since we started developing our new framework. The #1 issue would take a major essay to explain, but it relates to the RadComboBox alignment issue described above, or, basically the fact that large areas of the Telerik product suite are 'half completed', think the lack of certain templating abilities in RadGrid, the inability to override methods that actually render parts of controls, the inability to use the SkinRegistrar (a big issue with overriding rendering, obviously), the combo box issue stated above, etc (many etcs).
To clarify, we are developing our new framework using three third party product suites, so three different frameworks with the same functionality. Telerik is one obviously. While all product suites have their issues (major issues inclusive), Telerik has been both the easiest and the most difficult to use (sounds odd, i know), making it extremely difficult to make a decision regarding it.
To emphasize a few of the difficult moments with your product, we needed an entirely custom grid item, think a status bar like row, and be able to place it anywhere within the grid. This took a ridiculous amount of research and code (which translates to time and more importantly, money) to accomplish. Wasn't the easiest in the other product suites either, but took less than half the time than with your product in both cases. A fully custom pager (non-template) clocks in at 750+ lines of code (and seems to be accessed/created by your product 23 times for the non-visible top pager, but that may be our fault as it goes 23 times into the CreateChildControls method for the invisible pager), which is a rather large amount for some basic functionality (drop downs for page/page size, page links that display in specific formatting based on which page you are on (the majority of the code), etc). We actually gave up on custom column headers (for the column types you provide, so, ones that are visible in the grid, not entirely custom columns, which are a no no for us) because we started getting some ridiculous crashes within your entirely unreadable javascript, in the end it started taking too much time to develop (those are, however, complete and working for the other two product suites).
On the other hand, creating edit forms and such within your grid is extremely easy (as long as you stay away from using user controls). So, we're still not sure which product suite to use, and all three versions of the framework are practically complete by now, another headache inducing decision i will have to make.
The above goes for all three product suites, none are perfect (and aren't expected to be) but developing our own controls from scratch is just way too costly, although we may end up doing it anyway considering that we had to modify our functional and technical designs for all three versions of the framework several times because of issues with the third party product suites.
All this is hard to explain, since i am a systems analyst first, developer second i tend to look at the way you (and your competitors) designed the products as opposed to how i would use them in code. My developers are the other way around in this matter, they bring their development issues to my desk, and i translate those to design related issues (be it within our own designs or the design of the third party product).
Bottom line, i guess, is the fact that your product suite seems to lack 'design' in certain areas. Some things are extremely well done, better than other products, while others (the combo box, the skin manager, and many many smaller things within individual controls) are just plain 'coder design' and work entirely counter-intuitive (SkinManager) or do not provide enough functionality (RadGrid, Combo Box). The entire skinning system by itself is completely unlike i would have designed it (interesting detail being that at least two of my developers would design it the way you guys did, shows the difference between a developer mind and an analyst mind), and while it works, it has some major pitfalls that could have been entirely avoided.
Well, that's quite a rant i coughed up there, probably sounds a lot worse than it actually is (this sort of stuff in writing is very hard to assign a certain 'tone of voice' to, so apologies if it sounds badly here and there, not meant that way), these are just our observations in regards to your product, and i can produce similar essays regarding the other two products we are testing with, as i said, the decision is still up in the air between the three products.
Regards,
Mike
Apart from the issues, there is a fundamental design flaw with the SkinManager. It is simple, remove all skins (eg, set em to Default) from your page and they all look like 'Default', which is pretty much a giant eye-sore not to mention that it throws off any positioning entirely. the SkinManager may skin these things (if it remembers the skin that is, which i still say, it doesn't) but it only does so in run time.
Now, in our framework testing application, the main menu bar is WAAAAAAY too wide under the 'Default' skin, as opposed to, say, the Office 2007 skin where it is just over half the width of the page. So, the SkinManager completely and totally destroys ANY 'what you see is what you get'. The whole skin system is simply NOT made for such SkinManagers since the sizings differ enormously between skins, and it WILL destroy the look of an application if a skin is changed on the fly.
So, after sleeping on it, our conclusion as a company is that the new control is completely useless. Forget the 'reverse-designing' issue, forget about it seemingly not remembering the selected skin, throw it onto a fixed width site (like yours), change the skin and your page is totally ruined if the new skin has different sizes for the controls (RadMenu being the primary example), and i think most (if not all) skins have hugely differing sizes in them as compared to their counterparts.
This has actually been an issue for us for a while, even with just a single skin used. Take a RadComboBox (Office2007 skin), and plop it into, say, the pager of a RadGrid. The font size within the RadComboBox will become smaller due to the skin and location within the RadGrid, but the text in the RadComboBox (NOT the drop down (don't get me started on the drop down... MAJOR headache), the input itself, you know, the one that you cannot access from code-behind because it is created at run-time within a method that cannot be overridden) is now no longer centered vertically correctly and one needs to actually code some javascript to override the actual skin settings in order to get the alignment correct.
I think you guys need to re-evaluate your skinning system and actually make it work correctly before you can even think of a usable SkinManager. Better yet, start with a SkinManager and develop a skinning system around it. Refer to Infragistics for an example on how skins should work, even if theirs isn't (nearly) perfect either.
The whole skinning thing with the ridiculously complex CSS files has been our #2 issue since we started developing our new framework. The #1 issue would take a major essay to explain, but it relates to the RadComboBox alignment issue described above, or, basically the fact that large areas of the Telerik product suite are 'half completed', think the lack of certain templating abilities in RadGrid, the inability to override methods that actually render parts of controls, the inability to use the SkinRegistrar (a big issue with overriding rendering, obviously), the combo box issue stated above, etc (many etcs).
To clarify, we are developing our new framework using three third party product suites, so three different frameworks with the same functionality. Telerik is one obviously. While all product suites have their issues (major issues inclusive), Telerik has been both the easiest and the most difficult to use (sounds odd, i know), making it extremely difficult to make a decision regarding it.
To emphasize a few of the difficult moments with your product, we needed an entirely custom grid item, think a status bar like row, and be able to place it anywhere within the grid. This took a ridiculous amount of research and code (which translates to time and more importantly, money) to accomplish. Wasn't the easiest in the other product suites either, but took less than half the time than with your product in both cases. A fully custom pager (non-template) clocks in at 750+ lines of code (and seems to be accessed/created by your product 23 times for the non-visible top pager, but that may be our fault as it goes 23 times into the CreateChildControls method for the invisible pager), which is a rather large amount for some basic functionality (drop downs for page/page size, page links that display in specific formatting based on which page you are on (the majority of the code), etc). We actually gave up on custom column headers (for the column types you provide, so, ones that are visible in the grid, not entirely custom columns, which are a no no for us) because we started getting some ridiculous crashes within your entirely unreadable javascript, in the end it started taking too much time to develop (those are, however, complete and working for the other two product suites).
On the other hand, creating edit forms and such within your grid is extremely easy (as long as you stay away from using user controls). So, we're still not sure which product suite to use, and all three versions of the framework are practically complete by now, another headache inducing decision i will have to make.
The above goes for all three product suites, none are perfect (and aren't expected to be) but developing our own controls from scratch is just way too costly, although we may end up doing it anyway considering that we had to modify our functional and technical designs for all three versions of the framework several times because of issues with the third party product suites.
All this is hard to explain, since i am a systems analyst first, developer second i tend to look at the way you (and your competitors) designed the products as opposed to how i would use them in code. My developers are the other way around in this matter, they bring their development issues to my desk, and i translate those to design related issues (be it within our own designs or the design of the third party product).
Bottom line, i guess, is the fact that your product suite seems to lack 'design' in certain areas. Some things are extremely well done, better than other products, while others (the combo box, the skin manager, and many many smaller things within individual controls) are just plain 'coder design' and work entirely counter-intuitive (SkinManager) or do not provide enough functionality (RadGrid, Combo Box). The entire skinning system by itself is completely unlike i would have designed it (interesting detail being that at least two of my developers would design it the way you guys did, shows the difference between a developer mind and an analyst mind), and while it works, it has some major pitfalls that could have been entirely avoided.
Well, that's quite a rant i coughed up there, probably sounds a lot worse than it actually is (this sort of stuff in writing is very hard to assign a certain 'tone of voice' to, so apologies if it sounds badly here and there, not meant that way), these are just our observations in regards to your product, and i can produce similar essays regarding the other two products we are testing with, as i said, the decision is still up in the air between the three products.
Regards,
Mike
0
PureCode
Top achievements
Rank 2
Rank 2
answered on 08 Nov 2008, 01:16 AM
Oh, i should note that i did keep a very extensive 'log' of all the problems we ran into (for all three product suites), so if you guys would want a LOT more information going into frighteningly deep detail, it can be provided. It would take me some time to make it all readable and understandable, but considering the support Telerik has provided during the painfully long process of creating an entire enterprise framework in ASP.NET, it is the least i can do.
Regards,
Mike.
PS: Thanks for making the font size in the reply box larger, much easier to read/use now.
Regards,
Mike.
PS: Thanks for making the font size in the reply box larger, much easier to read/use now.
0
Hi Mike,
Thank you for the extensive feedback you have provided. We are definitely interested in working closer with you and helping you solve the issues you have encountered. If you send us sample pages where we can reproduce the problems we will do our best to address them. We are continuously working on improving our skins and you will see a lot more polishing and consistency in the coming updates. You will help us a lot if you send us your "log" with all the issues.
Greetings,
Ivo Nedkov
Unit Manager, RadControls for ASP.NET AJAX
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
Thank you for the extensive feedback you have provided. We are definitely interested in working closer with you and helping you solve the issues you have encountered. If you send us sample pages where we can reproduce the problems we will do our best to address them. We are continuously working on improving our skins and you will see a lot more polishing and consistency in the coming updates. You will help us a lot if you send us your "log" with all the issues.
Greetings,
Ivo Nedkov
Unit Manager, RadControls for ASP.NET AJAX
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
0
PureCode
Top achievements
Rank 2
Rank 2
answered on 12 Nov 2008, 08:09 PM
Hi Ivo,
How do you propose we continue from here?
As i stated in my previous post, it will take me some time to dig through all the notes i and my developers have created during our development process and create examples (many of the issues i will have to reproduce myself since they appeared in our framework and as thus have the potential of not being (entirely) related to your product suite, saves a lot of wasted time for both of our companies) for you.
There is a number i dealt with myself, so those are pretty easy to explain/show. Mine are, however, more design related than that they are bugs, or just plain questions regarding certain behavior RAD controls are displaying. These i can get done fairly quickly.
Would you prefer everything in one go, or gradually receive our issues as i complete my work on them? Keeping in mind that we are still using a trial version of Q3, which in itself is a 'design' decision on my side since we developed the entire framework on the trial versions, i'd rather complete the framework and then switch to an actual license, just in case it blows up with non-trial DLL(s) in which case we know what issues found cause it blow up, instead of resulting in a mixture of already existing issues and new issues.
Regards,
Mike
How do you propose we continue from here?
As i stated in my previous post, it will take me some time to dig through all the notes i and my developers have created during our development process and create examples (many of the issues i will have to reproduce myself since they appeared in our framework and as thus have the potential of not being (entirely) related to your product suite, saves a lot of wasted time for both of our companies) for you.
There is a number i dealt with myself, so those are pretty easy to explain/show. Mine are, however, more design related than that they are bugs, or just plain questions regarding certain behavior RAD controls are displaying. These i can get done fairly quickly.
Would you prefer everything in one go, or gradually receive our issues as i complete my work on them? Keeping in mind that we are still using a trial version of Q3, which in itself is a 'design' decision on my side since we developed the entire framework on the trial versions, i'd rather complete the framework and then switch to an actual license, just in case it blows up with non-trial DLL(s) in which case we know what issues found cause it blow up, instead of resulting in a mixture of already existing issues and new issues.
Regards,
Mike
0
Hi Mike,
Thank you for your willingness to cooperate.
We would suggest that you send us the issues "gradually" as you stumble upon them and have the time to describe the steps to reproduce.
But generally, any way that is convenient for you will be fine with us as well. We will of course reward all your efforts with Telerik points that can be used as a discount for your future purchases/renewals.
All the best,
Ivo
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
Thank you for your willingness to cooperate.
We would suggest that you send us the issues "gradually" as you stumble upon them and have the time to describe the steps to reproduce.
But generally, any way that is convenient for you will be fine with us as well. We will of course reward all your efforts with Telerik points that can be used as a discount for your future purchases/renewals.
All the best,
Ivo
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
0
PureCode
Top achievements
Rank 2
Rank 2
answered on 17 Nov 2008, 08:46 PM
Hi Ivo,
I had to visit a customer site out of state, so my apologies for the late reaction.
I'll make some time this week to get a few of the issues worked out and properly tested in order to start supplying you with some things.
Regards,
Mike
I had to visit a customer site out of state, so my apologies for the late reaction.
I'll make some time this week to get a few of the issues worked out and properly tested in order to start supplying you with some things.
Regards,
Mike