I have used both Telerik and Devexpress in projects in the past and while Telerik is good, it seems to lack some spit and polish. I am looking for someone who has the skill to disabuse me of the notions that I will be raising in this post. I WANT someone to prove me wrong so that I can feel good about switching to Telerik.
1. Created a Ribbon Form using the latest Telerik controls as of today, when I installed it. Went to create an application button menu item / description. Much to my surprise I found that something as simple as wrapping the description text was left up to me. In order to properly wrap this text, I am forced to create a compiler extension or library function (depending on your school of thought) that will take the output from the resource file and insert vbnewline entities after a certain number of letters. This might work ok for English but when I release the software in another language, this wrapping function will likely have to be internationalized so that it will properly wrap something other than english. I simply find it hard to believe that a product that certainly competes in many ways with DevExpress cannot handle this. (I have gripes with the ribbon control from devexpress too, its lack of support for anything bigger than a 32 x 32 png icon is maddening).
2. The ORM designer does not tag the the classes it generates with <datamember> or <datacontract> attributes and the documentation for this leaves much to be desired. If you go with a code first approach it seems that there is a large amount of code that you need to write on your own to handle the data context duties. The code first approach from devexpress seems to be more poco and I can decorate those classes with attributes that will end up feeding the database engine things like field length (for nvarchar) and so on. Specifically there are additional classes that you need to hand code that the devexpress orm model seems to handle for you in that framework.
It is true that I did not attempt to take these generated classes and run them over the service boundary, but given the testing I have done in the past, WCF services pretty much will not serialize unless you have these attributes on your classes.
Now, if someone can disabuse me of these two notions I am all ears. I am submitting this to the community as a challenge, especially someone who loves Telerik. I do not dislike Telerik, but I reviewed it a number of years ago and found it lacking at that time (around 2008), and recently I won a copy of it at a .NET user meeting, so I tried it again, and found the issues above, again, causing me surprise that the product actually had these kinds of limitations being as mature as it is.
No product is perfect, I understand that, but the first issue seems to me to be easily implemented from a control perspective and the fact that it is not, leads me to wonder... what else will I run into if I adopt this product?
The ORM issue again, while not simple, it seems to me that it could be automated and that I could inherit a class that implements the needed capability in my poco class and it would have the data context methods already available to me, not as simple as the first issue I raised, but still seems to be a fairly straightforward OO design issue. (just talk with JP at www.developwithpassion.com) and he'll tell you its a simple OO problem and probably code you the answer in about 60 minutes.
Anyhow, these are my thoughts after a day of review of this product. If someone can disabuse me of these notions and provide fixes that will work under all the scenarios I have outlined, I would love to hear it.
Cheers,
B
1. Created a Ribbon Form using the latest Telerik controls as of today, when I installed it. Went to create an application button menu item / description. Much to my surprise I found that something as simple as wrapping the description text was left up to me. In order to properly wrap this text, I am forced to create a compiler extension or library function (depending on your school of thought) that will take the output from the resource file and insert vbnewline entities after a certain number of letters. This might work ok for English but when I release the software in another language, this wrapping function will likely have to be internationalized so that it will properly wrap something other than english. I simply find it hard to believe that a product that certainly competes in many ways with DevExpress cannot handle this. (I have gripes with the ribbon control from devexpress too, its lack of support for anything bigger than a 32 x 32 png icon is maddening).
2. The ORM designer does not tag the the classes it generates with <datamember> or <datacontract> attributes and the documentation for this leaves much to be desired. If you go with a code first approach it seems that there is a large amount of code that you need to write on your own to handle the data context duties. The code first approach from devexpress seems to be more poco and I can decorate those classes with attributes that will end up feeding the database engine things like field length (for nvarchar) and so on. Specifically there are additional classes that you need to hand code that the devexpress orm model seems to handle for you in that framework.
It is true that I did not attempt to take these generated classes and run them over the service boundary, but given the testing I have done in the past, WCF services pretty much will not serialize unless you have these attributes on your classes.
Now, if someone can disabuse me of these two notions I am all ears. I am submitting this to the community as a challenge, especially someone who loves Telerik. I do not dislike Telerik, but I reviewed it a number of years ago and found it lacking at that time (around 2008), and recently I won a copy of it at a .NET user meeting, so I tried it again, and found the issues above, again, causing me surprise that the product actually had these kinds of limitations being as mature as it is.
No product is perfect, I understand that, but the first issue seems to me to be easily implemented from a control perspective and the fact that it is not, leads me to wonder... what else will I run into if I adopt this product?
The ORM issue again, while not simple, it seems to me that it could be automated and that I could inherit a class that implements the needed capability in my poco class and it would have the data context methods already available to me, not as simple as the first issue I raised, but still seems to be a fairly straightforward OO design issue. (just talk with JP at www.developwithpassion.com) and he'll tell you its a simple OO problem and probably code you the answer in about 60 minutes.
Anyhow, these are my thoughts after a day of review of this product. If someone can disabuse me of these notions and provide fixes that will work under all the scenarios I have outlined, I would love to hear it.
Cheers,
B