Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
why should i use telerik radcontrols over visual studio built-in controls. Basically i want to know the pros and cons of telerik controls.
I am new in telerik. I really get very less time for learn something new.
So is it worthwhile to choose telerik over other new technologies.
We use Telerik a lot, togheter with the standard set of controls.
Pros
Prevents you from reinventing the wheel. For example, RadScheduleView and their charts are powerful, if you need them.
Tons of controls, for almost any need
Look and feel-consistency
The huge library of demos and examples provide a solid base when you want to rapidly do or test something
Extensive documentation
Great support from the staff and community on their forums
Widely used - almost every issue encountered has an answer
Quite good MVVM-support
Cons
Some controls are sub par performance wise, but it has gotten better over the last few years
You probably wont use most controls
Your application tends to get rather large (even with optimizations)
The learning curve for some of the most useful controls can be steep, depending on the experience you have
Customization of some of the controls is cumbersome
Some controls don't offer much above the standard ones
My tip is to find out what you want to do, and check if they have a control that seems to make the cut - and try it!
Advantages:
By using this control our lots of coding is reduced. For ex:- Telrik Grid automatically handled Pagging,Filter,Sorting...etc. So, we can reduced development time.
Using telerik style builder, we can easily create our custom theme to match our site theme.
Any .net developer get good hand on this control in very short time.
We can get easily support from telerik team, telerik mvp and telerik users.
In trail demo all the features is available, so we can implement this controls in our page and check the how it looks and match our requirement.
Demos and documents available in live. If internet is not available in our system then we can also install this demo in our system and we can check it offline.
The number of control is very high so after buying this control we do not need to buy any other control.
In-addition its controls also provide client side events and api.
RadControls is a complete ASP.NET AJAX development toolset .It includes more than 70 versatile and performance-optimized components that help you build high-quality, professional line-of-business projects. RadControls speed up UI development up to 5 times and allow web developers to focus most of their time on implementing business logic.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I believe that one needs to buy a license(?) to use devexpress. I'm currently implementing a gridview and want the sorting arrows to appear in column headers. I know that devexpress grids have that feature and I believe many more? Could anyone point out any specific reason why someone would pay for using a devexpress grid, or I guess the devexpress suite comes with a lot more than just grids?
Could anyone point out any specific reason why someone would pay for using a devexpress grid, or I guess the devexpress suite comes with a
lot more than just grids?
Here is your reason of paying for the third party controls, In Short features give preference to use these rather than the standard controls.
it’s unlikely for the client to have a specific request about some user interface component that can’t be satisfied with either default controls or 3rd party controls. Many of the convenience aspects like detailed view, sorting, auto completion, filtering, and changing perspective have already been solved by the 3rd party companies over the several versions of the controls.
When in need for some UI functionality, it’s better to search the companies’ websites for something suitable, instead of trying to develop from scratch. It will also certainly be cheaper than going over the document, develop, debug, test, and deploy cycle countless times.
By using 3rd party controls it’s easier to keep focus on the actual business functionality for your project, to spend time developing visible features for the application, than to work on solving the many background technical difficulties associated with developing every functional request.
On the other hand, if you reach the conclusion that the control would require some serious modifications in order to suit your needs, it’s probably better to do the entire development in house, eventually based on the simple default controls that come with the .NET Framework.
For example, I do use devexpress controls, on which project i am
working they specially require a developer with knowledge of
DevExpress control, because that will reduce the development time(
Project completion Time also) rather than using the standard control.
The Specific requirement make them to pay for the controls as those
guys commented in this SO thread.
Check these for feature comparison - Standard GridView vs DevExpress GridView. I like it's client side functionality..
Here's a reason. Because they want sorting arrows in column headers. Also, any of hundreds of other features these products provide that the default grid does not.
The point is, the extra features ARE the specific reason.
Not only does it take care of operations such as sorting and search. It is actually very useful in helping you populate data from your database easily by quickly mapping your fields to IQueryables (If you are using C# and not DevExtreme). If you're using the grid on many pages in your platform, you can easily configure all these grids from one single point (Themes, Functionality, Configuration, etc...). It also provides additional security measures to prevent certain injection attacks. Finally, it is always updated with new features and improvements with constant releases. One really important thing too is that the DevExpress help center and forums are very rich and you will find an answer for almost any question or issue you come across. So using the DevExpress component will bring scalability and increase reliability with time for your platform.
I have come across the ASP.NET ready made controls like grid, repeater... etc.
For example while dealing with GRID i remember following facts,
ASP.NET V1.1 has DataGrid with "virtual row count" which is heavily used for custom paging which is need of big sites to perform well.
ASP.NET V2.0 added the GridView with all sort of cool features but also split the DataSource parts as different component. Also "virtual row count" is not supported and for pagination to be done DataSource control is need to be used.
After all these thing i thought that ASP.NET control are not made to be used as is for the development.
Please let me know whether i am right or wrong? Also if you think i am wrong PLEASE provide inputs/links which can help me come out of this thinking of mine.
The mjority of the out-of-the-box asp.net controls are very simple, easy to use and they do that they claim to do, reliably. Many people have had issues with the GridView control, particularly with regard to preformance and size of ViewState. Performance issues have only partly been resolved through the use of AJAX.
I agree with #Neil Moss about the Repeater control. It is very flexible and it outputs what you tell it to. For grids, take a look at the JQuery plugin JQGrid. It has none of the performance issues and a lot of the powerful features of many thrid party custom grids. http://www.trirand.net/demoaspnet.aspx
Also, the ListView control is a very good alternative to the GridView as it provides many of the databinding, selection, paging, sorting, modifying features of the gridview (see here) but gives full control over the output template. Here is a good series of articles on the ListView
Although I am a strong advocate of using ASP.NET MVC, there is a considerable learning curve required to do this and the change in mindset required to work properly in the MVC way should not be underestimated.
I've never had a problem using these controls. I find that they have the same advantages and disadvantages as any set of controls - native or third party. If they do 100% of what you need them to do, then fantastic. If they don't give you 100%, and don't give you events or virtual methods to override, then you're stuck and you'd need to go back to more fundamental controls and do a little programming of your own. I always found the repeaters and lists to be very handy in that respect.
to be very short & direct, ASP.NET ready made controls are the best solution for most projects.
I’ll explain you in detail, but first, ASP.NET ready made controls are known as ASP.NET Controls Framework or ASP.NET Controls Library. I am insisting on the key phrases because, when you search google like search engines, you need to search by appropriate keywords to get better results.
There are many control libraries available on the internet and most are offering free tools too. Besides the question whether should I use it in my enterprise applications or not, you need to understand your requirement.
The first point is YES, you can absolutely use the controls in your enterprise applications, because there controls are more reliable and built by control development experts, tested by strong product testing team and are enriched with quality documentation. Note, you will also get good community support, human resources with controls knowledge, and compliance with industry standards. The best of all, you will be able to save your time on all the above factors. Some controls even gain you more advantages with its features & functionalities which you wouldn’t have even thought about.
The most important things you need to do when choosing a control
1. You need to go through their knowledgebase
2. Search relevant articles for the control you choose
3. Download evaluation version and DIY
Many good control libraries are available in the internet. I am using obout control libraries and I recommend you to go for obout. Besides quality control sets, these guys provide personal development support. Most time I can’t separate them from my internal team. Check www.obout.com for yourself.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
We started a new project and the nature of the project is very interactive and a Rich UI is required.
We would need a set of controls that would require for Rich UI development. I found Obout while googling. I never heard about them and never seen fellow members telling me such name except Telerik, ComponentOne, NetAdvantage. These are the famous names we heard but no this one.
But, the controls give a positive feeling. But as two things matter always when you are buying some services: How good are their customer support? and How much feasible their price is?
Another, how quickly they release patches/updates? As, what if we find a bug or an error during development what will going to happen? Do they provide a quick solution for this?
I'm bit confused making a decision here. I need your assistance, experience and feedback.
I've used Obout controls before. They are definitely lesser known than something like Telerik or ComponentOne, but they've been around for quite a while and definitely put out a quality product. They are also a good deal less expensive. Overall I had a very positive experience with them and never had any trouble with support requests at all. My first experience with them was about 5 years ago and they were very good then, and they've only gotten better.
I don't know specifically how quickly they put out releases, but I can tell you that over the past few years they have released a whole lot of new stuff. I believe you can download all the controls and try them out before you buy them, so I would encourage you to do that. If it meets your needs and you find it easier to use than the alternatives then go for it.
Also check out this question to see some additional feedback: Obout controls in C# .Net
Don't think so. I bought their suite and everytime i tried to use one of their controls, it sucked.
Example 1.
I use their grid and want to take advantage of the filtering options. For 400 records, the grid only filters in the twenty records that are on the first page. So it leaves out the majority of the records. I got in contact with their support and i sent them the files they asked for. That was five month ago and despite repeated tries and emails, i never got an answer.
Example 2:
Today i am using their datepicker. Nice try, but it opens in a weird position on the page and there is no possibility to change that.
We have been using their tools for over a year now, and we are very pleased with them. The cost is a fraction of what the competition is charging. They work great, they look nice and it reduced our development so that our project was completed two months before expected, even with learning the new tools.
The learning curve is a little steep, but that goes for any of the comparable packages. The tech support sucks, by email only. When we first purchased it they had a support forum and you could find most of your answers in the forum, but sadly they did away wit hit. Now it takes a few days to get a response. But when doing an entire application, we had plenty of pages to work on while waiting for responses. Most of the time they pointed out the problems or told us how to resolve them. And I sent them many messages telling them to disregard previous queries, having found the answers on the internet.
Their examples are simple, and if your needs are simple they will suffice. If building a full-blown application to replace a legacy application and run your business, such as we did, you need better support. Still, it was money well spent. We use the grid and filters to perform searches on our client database of 200,000 records, and can usually find the person we need in less than 10 keystrokes by name alone. Performance is very good on our intranet.
I will note that when I thought I had found bugs in the software, it was just me. A comma where a period should be, bad capitalization, misuse of functions, etc. Javascript is very sensitive with it's syntax and not friendly with error messages, so much time was spent going over code to discover the not-so-obvious errors.
And our demands are probably beyond most peoples needs, our main screen has a combination of a superform and 7 data grids, each of which pops up a modal form for data entry, all within the same web page. But it does the job well. All in all, we have about 60 data entry pages and another 60 reporting pages we created with the oBout tools. The reporting pages allow the users to set report criteria (i.e. dates, clients, products, etc. using popups, calendars, radio buttons, etc.) and pass these to SSRS reports, a sort of ad-hoc reporting. So we created a projects with over 125 web pages and over 150 reports in less than one year, quite an achievement considering the small workforce.
If I were you I'd look strongly at using jQuery and the hundreds of great plug-ins that will provide just about any functionality you need. jQuery is heavily supported and best of all it's free (open source).
It will provide all the client-side functionality you need and it's VERY easy to work with. One of the things you really need to use jQuery is to have control over the id and names of your HTML controls (DOM elements). When you use those third-party control packs (and most of the built-in ones in .net too) you typically lose a good deal of control of the HTML they produce. You can either wait for asp.net 4.0 to come out which will resolve the control id issues or rely on repeater controls and have complete control over the ids and other HTML it produces.
It's well worth the small investment in learning jQuery and the repeater control if you haven't done so already.
I used Obout controls several years ago (from memory, their ASP.Net TreeView and Slidemenu).
I think I had to contact them on a couple of occasions, and received prompt support both times, solving the problem we had.
However, whether their controls (in terms of UI, API) meet your expectations is quite a personal thing- the support is good, but you might find that you don't like the look of them, or the API doesn't fit in with the way you do things (although it was fine for me). You should really evaluate them yourself and see how you get on with them.
if you don't need something too well integrated into asp.net, definetly have a look at extjs. its THE rich ui library.
I am using Obout controls. And clearly I would have done another choice If I could. The controls are bulky and quite often buggy when you try to inherits from them. A poor choice to me.
Curious if others feel the same as me. To me, controls such as datagrid/gridview/formview/etc. are great for presentations or demo's only. To take the time and tweak this controls, override their default behavior (hooking into their silly events etc.) is a big headache. The only control that I use is the repeater, since it offers me the most flexibility over the others.
In short, they are pretty much bloatware.
I'd rather weave my own html/css, use my own custom paging queries.
Again, if you need to throw up a quick page these controls are great (especially if you are trying to woo people into the ease of .NET development).
I must be in the minority, otherwise MS wouldn't dedicated so much development time on these types of controls...
Anyone that thinks nobody uses *Grid controls has clearly never worked on an internal corporate webapp.
I'm pretty much writing my own HTML - I'm using the ListView and Masterpages, but not really using the controls much anymore. My ListView laughs at your silly old repeater, by the way.
However, bloatware isn't necessarily a bad thing. If I needed a low volume intranet application built, I'd much rather pay a less experienced developer to drag and drop controls than for an HTML twiddler (like you or me) to craft each tag. There's definitely a place for the quick, simple approach. What's the cost of "bloatware" in that scenario, as long as the control based code is written in a maintainable fashion? Often wiring controls together requires less custom code, which means simple maintenance.
The one place I have to disagree with you - pretty much regardless of the application - is in crafting your own paging queries. You may like to do that kind of thing, but there's absolutely no business value in it. There are several professional-grade DAL tools which will usually write more maintainable, faster queries than most developers. Even if you lovingly craft the perfect paging query, it won't keep up to date with changes to the schema unless you continue to throw hours after it. I think better use of those hours is to build a lightweight system and put those hours into monitoring and fixing specific bottlenecks, rather than immediately jumping to the "database assembly language" layer.
I've been reading your posts guys and it made me feel dumb.
I mean in every application I made where I work there is at least one datagrid/gridview in it. And I didn't have the feeling I am missing something.
Sure I find datagrid/gridview kinda bloated but are they that much disgusting to use?
I think you need to learn to use GridViews before you condemn them. I use them extensively. At first it was a bit challenging to figure out certain things, but now they are indispensible.
GridViews within UpdatePanel with AJAX CRUD and pagination are lightning fast. One of the larger systems set up this way (for internal/external application) has a moderately sized db in the backend. There are many nvarchar(2000) fields and the transitions and updates are great.
In any event, if you've written your own version of displaying data, you may want to continue using it if it works. (Same argument could be made for writing your own compiler, writing your own version of HTML, writing your own version of data access binaries...) The advantage of using GridView is that there are a lot of people who are familiar with it and that MSFT has abstracted/modeled the class to do a lot of things that we used to have to do manually.
Every single app we development at my company has grids (the apps are all behind the firewall). That includes both web apps and Winform apps. For the web apps it's the good ole gridview with custom sorting for the winform apps we use Janus grid. I'm trying to get the developers/users to think of a better user interfaces but it's a tough to change. I gotta admit its still better than the alternative of the users building their "own" apps with Access that I would then need to support!
Using controls like the GridView are great for simple apps. Even if you are a server-side HTML bracket-twiddling ninja, they can make developing simple stuff much less time consuming. The problem is that they usually start to expose their shortcomings eventually, and you end up having to spend time tweaking them anyway. But at least you can get up and going quickly to start out with.
For example, the default paging in a GridView doesn't support paging in the database itself (you have to load all the rows before it will page them), so once you start feeling that pinch in performance, you may need to think about rolling your own or, perhaps better, find a more capable grid control.
Anyway, the point is that pre-built components are good. They help. But as usual, it depends on what you need them to do.
I've actually used GridView extensively for an adminsitrative console. I even created a custom DataFieldControl that sets the field's header text and sort expression based on data field, creates an Insert row in the bottom and automatically collects the values in the row and forwards them to the data source's insert method, and generates a list box if an additional list data source is specified. It's been really useful though a huge time investment to build.
I also have another control that will generate a new data form based on the fields' metadata when there are no records (in the EmptyDataTemplate).
<asp:GridView ...>
<Columns>
<my:AutoField HeaderText="Type"
DataField="TypeId"
ListDataSourceID="TypesDataSource"
ListDataTextField="TypeName" />
</Columns>
<EmptyDataTemplate>
<my:AutoEmptyData runat="server" />
</EmptyDataTemplate>
</asp:GridView>
I really like the telerik radgrid. Their product ain't cheap, but you get a lot of controls and features. And the data binding support is pretty good, both in a simple asp.net data source binding way and in a more custom handle-your-own-databinding-events kind of way.
At my company we use grids everywhere, mostly ComponentArt Grid (http://www.componentart.com/). Yeah it's bloatware but you get a lot of functionality that wouldn't be much fun to re-invent: sorting, paging, grouping, column reordering, inline editing, templating (server-side and client-side). The client-side APIs are nice too.
I like the GridView control and have used it in several custom DotNetNuke modules for my company's web site. For one thing, using the built-in controls means less dependencies to worry about. And once I had it set up how I wanted it, I basically copied the code to other pages and just had to do minor tweaks.
I've found that there are so many options with modern grid controls (Infragistics, Telerik, etc) that it takes longer to configure the grid than anything else. The MS controls are pretty simple yet they can do pretty much anything.
They are one of the benefits of asp.net. Up until just recently I hated them, but the more you use them the easier they become, once you learn what setting you must change for which instances. Mainly I like the form view and listview the gridview still needs some work.
We use the Infragistics UltraWebGrid + LinqDataSource on our intranet apps.
It gives us ajax, sorting, filtering, paging all server side.
The "export to excel" also is a killer feature.
We have 5000+ users,lots of data, performance is excelent.
I largely abandoned grids once I started designing from user stories, rather than from database table requirements. And never editable grids. The old way was just how we coerced users into doing data entry/table maintenance for our systems, and it never matched their workflow - any real job ended up skipping from one master/child form to another.
And the users never figured it out - but they sure knew our applications were harder to use than they should be.
An exception is analytical applications. But there are relatively few of those, and they are largely read-only.
I too would like to see an expanded answer on why GridView et al are considered "bloatware." I have extensively used GridView as well as 3rd party products (Telerik, etc) and find that for the majority of internal and some external projects, they work great. They are fast, easy to use, customizable - and BEST - I can hand them over to someone who knows GridViews who can then easily pick up where I left off. If I were to hand-code all of the numerous apps/controls, the overhead in the next person figuring out what is going on would be enormous even under the best of circumstances.
For me, I can see some of the 3rd party products being bloatware (but still sometimes useful), but the bare-bones GridView I've found to be quite fast with moderate queries.
For my corporate intranet projects, grids are indispensable. They are the foundation for easy reporting on the ASP.NET webforms platform.
Easy to Design
Paste the grid on the page. Insert BoundField objects for simple binding. asp:HyperlinkField for easy linking.
Binding
You can bind grids in a handful of ways:
a collection of objects (List, ArrayList, Hashtable, or any simple collection)
SqlDataReader in your code-behind (yikes, that would require SQL in your presentation tier)
SqlDataSource (specify a stored proc. All the columns on the resultset map directly to the grid's columns. It's a very quick and dirty if the report doesn't mimic your domain object nicely. i.e. summations of different things.)
objectDataSource (binding to a method on your BL)
For those who might call out SqlDataSource and ObjectDataSource, you don't always have to have them declared in your .aspx.cs or .aspx.vb . I am not advocating them here, just pointing out the possibilities.
I don't think you can discount the RAD benefits of the built-in GridView and other 3rd party grids. Management types love and want tabular data.
Components like the GridView/FormView/DataGrid follow the 80/20 rule.
This means that 80% of the time when you use them for simple purposes they get the job done and are extremely easy to implement.
But 20% of the time you will be trying to build something complex (or weird) and you will be forced to jump through a dozen hoops and bend the code in many ways to try to implement a solution.
The trick is to learn whether the problem is an 80 problem or 20 problem, if you can identify the 20 problem early you are much better off writing the code from scratch yourself and ditching the "time saving" one.
I use them extensively in the corporate environment I work in and I'm working with one right now. The people who don't use them remind me of all those "I built it with Notepad" developers of years past. What's the point of using asp.net if you're not going to take advantage of the time savings?
I have never used it. I completely agree, it's bloatware. I usually end up using the repeater with custom controls that i made.
For anything long term I would try to avoid datagrid/gridview, it sometimes becomes too hacky making it do exactly what you want, after a certain number of these tweaks you start to realise its not saving time in the long run and you might not be getting the control over markup that you need.
However the built in paging and sorting functionality works well and in 2008 there is a new ListView control which aims to sort some of these problems out and give you tighter control of the html that is output.
I have wondered about this for a long time. There seems to be a consensus here that the grid controls are bloatware. But, can anyone definitively cite the cost of using these controls? Is there excessive HTML sent to the browser? Too much resource devoured on the server? Is generating the HTML table faster (assuming it's well-written)?
In addition to the bloatware issue, I have often run aground when UI requirements are enhanced to include features beyond the scope of the standard controls. For example, in early ASP.Net versions, I struggled with putting images in column headers. And, I believe it's still a challenge to add a second, top-level header row spanning multiple columns. At some point, it becomes really difficult to wrestle with the control to achieve the desired effect. And it's frustrating if you know the HTML you want, but you just can't make the control do it.
On one project, I finally gave up and wrote myself an HTML table class to generate a very complicated grid. It took a couple of days to get it just right. But, now I have the basic code, and it will be much more efficient to tweak that for future grids.
No doubt about it, though. It's hard to beat the fancy grid controls for speedy development, if you can just live within their limitations.
If you work with designers a lot on public facing web sites then you should ditch the GridViews and stick to repeaters. That's my opinion anyway - I've had to pull apart hundreds of GridViews and turn them into simple repeaters in order to fulfill the design requirements.
If you go near DataGrids or GridViews with a 10-foot pole on a public facing web site then you HAVE to use the CSS friendly Control Adapters. (At this point you might find it easier just to do it in the Repeater.) Prior to Control Adapters being available I would have considered these controls broken out of the box.
I find that too many .NET developers do not have a good understanding of design, accessibility, CSS, javascript, standards etc. which is why they succumb to GridViews, ObjectDataSources etc.
GridView is fine and very powerful control and works well with css or theme. The only thing that is annoying me is that VirtualCount property was dropped when old 1.1 DataGrid was replaced with GridView in asp.net 2.0 and it was useful for implementing custom paging. However same can be done via data adapters.
Though working with repeaters is maybe clearer and you have total control over rendered html still I wouldn't recommend going on that ways because is harder to implement and maintain.
I never really used the standard WinForms grid before but at my last job we used the ComponentOne FlexGrid extensively and it worked beautifully. There were still some annoyances with trying to get all the customization we wanted but overall it saved us a ton of time and produced beautiful results.
Currently I'm working with Silverlight 3 and RIA Services and I can't imagine trying to produce what we're doing without the DataGrid and DataForm controls. The time being saved far outweighs any of the overhead.
i am a moderate level developer i can say without these controls i couldn,t ever learn developing.just you have to admit yourself to it for a while till you find your way to customize it and the end result will be great
I'm trying to look at it all in context. I have a page that has a nice gridview (displays 10 rows at a time, 6 columns, sorting, and paging) and if I just look at the html table that is created along with the viewstate, I'm only seeing 29k of code.
Is 29k vs. 18k for using a repeater or listview really worth all the effort in these broadband times?
I personally stick with the gridviews however the design guy I work with sometimes gripes about trying to style it via css.
Just reading your posts. I agree PHP is easier than asp. but I just started using visual studio for formviews and gridviews. Can not get much easier for either vb or C# programmers. ASP still has problems uploading large files. PHP it's a snap. I run PHP under IIS 7.5