We have an ASP.NET silverlight application, which is becoming limited by the requirement to have Silverlight installed.
I'd like to switch to a new framework, but don't want to have to build an entire new system from scratch. Ideally I'd like to find a third-party framework that has all of the basics available right out of the box, so we can start adding our pages to the application and use our current business logic (mostly WCF calls). Telerik & ComponentOne seem like good places to start, but so far I haven't seen either of them have a "complete" application that we can use as a starting point. Am I missing something? Can you suggest other frameworks? I'm really looking for something that gives us a great jumping off point to develop a rich UI in as little time as possible.
Some features I'd like to see are:
User authentication/registration/preferences
Custmomizable Site navigation map
Pages avaialble based upon roles
Rich UI experience (right clicks a plus)
I can speak for Telerik as I am one of the evangelist for Telerik. We at telerik have 70+ controls on the ASP.NET AJAX front and they all are RAD controls. You can just drag and drop and you have the flexibility to use a GUI to set the properties or through HTML or through code behind. We complement whatever ASP.NET has to offer and because of that there is no separate learning curve involved.
To get you a feel of completeness - I suggest that you take a look at the following integration examples - an end to end scenario apps.
Olympic Games - http://demos.telerik.com/aspnet-ajax/sample-applications/olympic-games/
Image Gallery - http://demos.telerik.com/aspnet-ajax/imagegallery/
Sales Dashboard - http://demos.telerik.com/aspnet-ajax/salesdashboard/
Rent A Car - http://demos.telerik.com/aspnet-ajax/carrental/
Schedule Builder - http://demos.telerik.com/aspnet-ajax/schedulebuilder/
Web Mail - http://demos.telerik.com/aspnet-ajax/webmail/
Ecommerce - http://demos.telerik.com/aspnet-ajax/ecommercestore/
Whats more - all these demos can be downloaded and you will get the source code. So you can base your project right out of these samples.
Please go through all the above integration examples. Hope this provides some insight into your decision making process.
Also we do have an HTML5 based JavaScript UI framework called Kendo UI. This is a complete client side control rendering using javascript which will speed up your apps like anything. And this can be used in ASP.NET MVC scenarios as this fits very well in those. Nevertheless whether you use MVC or not you can still make use of the HTML5 based JavaScript Widgets available as part of the Kendo UI on any web application platform.
http://demos.kendoui.com/web/overview/index.html
Hope this helps you !
Related
I would like to create an UI for my app ( current I've an UI in WPF ) and I like the "Single Page Application" paradigma. I'm a little stuck on how to start implementing it: I don't mind about SEO, mine is an enterprise application. Do I need to use something like sammy.js, backbone.js and so on? I'm really new to Web GUI developement and I'm a little consfused: why can't just use jquery calls to drive my single page DOM? Is there some drawbacks about this strategy?
Checkout this series of blog posts by John Papa this could give you a jump start...
http://johnpapa.net/building-single-page-apps-with-knockout-jquery-and-web-api-ndash-the-story-begins
http://johnpapa.net/spapost2
http://johnpapa.net/spapost3
http://johnpapa.net/spapost4
http://johnpapa.net/spapost5
Hope this helps
First of all, you can do your single page application with jquery only. However, you will be writing a lot of plumbing code to handle interactions between the different parts of your UI. Which is not the most interesting part of the developmnent process, especially if frameworks do it nicely for you.
You should have a look at this question : https://stackoverflow.com/questions/5112899/knockout-js-vs-backbone-js-vs, and decide between knockout and backbone.
For implementing a simple master-detail UI (left column for listing items, right column for display, jquery popups for more details or editing), I chose knockout, and was not disappointed.
The learning curve is not as steep as backbone's, and coming from a WPF MVVM app it was easy to understand the development paradigm.
I chose ASP.NET MVC to serve the html templates using ViewResults, and after that everything went through JSON.
Knockout made this easy because of it's client side databinding capabilities. Then, when posting data back, MVC modelbinding made server side binding easy as well.
You could use just jQuery but it can soon become very hard to manage if not designed very carefully. Take a look at knockout.js which is mvvm it's great for managing state and reacting to events.
If you develop SPA then your best choice would be knockout.js+MVC+Ajax/jQuery
I'm getting ready to be responsible for leading the development of a small ASP.net MVC application. This is my first time creating an MVC application, so I am excited!
I've carefully read over the documentation and I feel like I have the general idea of how MVC works. However, if I understand correctly, server controls (like GridView, for instance) are not part of MVC.
My question is: Why? At my development shop, I'm so used to using controls like GridView and the MS Chart Controls that I'm almost at a complete loss as to developing without them. It seems almost like starting over.
Why are the server controls unavailable? How does Microsoft expect me to work without them? What are the alternatives?
My question is: Why?
Because most of them depend on things like ViewState and the Postback models which are part of the classic WebForms model and no longer exist in ASP.NET MVC. Those server side controls rely on events that will perform postbacks to the server persisting their state in hidden fields (ViewState). In ASP.NET MVC you no longer work with events such as Button1_Click. In ASP.NET MVC you work with a Model, a Controller and View. The Controller is responsible for receiving user requests, querying the Model, translating the results into a view model and passing this view model to the View whose responsibility is to display it under some form.
In ASP.NET MVC there are HTML helpers that could be used to generate some reusable HTML fragments between views. You may take a look for example at the Telerik ASP.NET MVC suite of such helpers. They call them controls but they have nothing to do with classic WebForms server side controls. They are just HTML helpers.
Basically classic WebForms are a leaky abstraction of the web. What Microsoft did back in the time when they designed this framework was to bring existing Windows developer skills to the web which was getting more and more momentum. But since the web was still a new technology that most developers weren't yet familiar with, they created this abstraction to hide away the way that the www works. Those developers were accustomed to drag and dropping controls on their Windows Forms, double clicking on buttons that was generating some code for them in which they put their data access logic and so on. This model was transposed to web application development thanks to WebForms. The HTTP protocol was successfully hidden behind this abstraction called WebForms. For example you don't need to know HTML, nor Javascript, not even CSS in order to create a website using WebForms which is really great because the framework abstracts all those things for you. Unfortunately by doing so it prevents you from easily utilizing the full power of lower level web technologies which some people might need when developing web applications.
What ASP.NET MVC does is basically remove this leaky abstraction and bring the www to the developers the way it was intended to be by its creators. ASP.NET MVC is not mature enough compared to classic WebForms so you cannot expect to find the same range of available controls and widgets but things are slowly shifting.
I would recommend you start here with ASP.NET MVC: http://asp.net/mvc. Go ahead, watch the videos, play around with the samples and see if ASP.NET MVC is for you or not. And of course if you encounter some specific difficulty or question don't hesitate to come back here and ask it.
I'm so used to using controls like GridView and the MS Chart Controls that I'm almost at a complete loss as to developing without them. It seems almost like starting over.
In this case, starting over is good.
I've gone through a similar journey. If straight HTML scares you, try working with the System.Web.UI.HtmlControls namespace. This will allow you access to standard HTML controls, but you'll still have the comfort of turning them into server controls if you need to (either by specifying the runat="server" attribute, or by converting them into equivalent ASP.NET controls.
In addition to Darin's answer, there's another problem with ASP.NET: you're bound to Microsoft's view of the web. That GridView you love? It's generating bad HTML. The Paging controls it provides? Even worse. Even if you know very little about HTML compliance, nested tables should give you the chills. In a way, everyone who uses a GridView is lucky that legacy web supported by Microsoft (and to a lesser degree, Google and Mozilla) came from such a god awful starting point.
Finally, to summarize: my suggestion is that you try to rewrite your pages or develop new web applications (as best as you can) using HtmlControls only. You'll probably have to learn some JavaScript/jQuery, and might have to venture into the world of AJAX to make your controls operate the way you want them to.
Use this as a stepping stone into the world of MVC. You won't use the same technologies (and may drop a lot of JavaScript/jQuery), but it will help you change the way you think about web development in much smaller, and perhaps easier-to-absorb chunks.
Ultimately, however much you like your ASP.NET controls, you'll have a much greater degree of freedom, and you'll also be developing websites that make use of newer technologies, which will provide added value to your websites.
At the core of this is Model View Controller (MVC) which promotes decoupling. The idea is that you feed your View (web page) a Model with all the data that it needs to be rendered. Server controls are tightly coupled. There is no concept of state in MVC or 'should' be no concept anyways.
That's kind of the point of MVC. It takes away the high level of UI abstraction that server controls provided and leaves you with html and javascript. (It also adds some really cool model binding features)
I am new to MVC and have found using Partial Views to be similar in creating small, reusable UI elements that do not fit into the _Layout. For example, sliders, slideshows, navigation, featured sections although you can use #section for this I find partial views to be more beneficial. This concept enables me to create reusable libraries that I can switch out easily and use in other projects. To me this is similar to controls, although there is a debate both for and against this analogy.
What technology was used to create the User Interface of "Smartermail" by Smartertools and the User Interface of "Action Method" by Behance?
They both have great user interfaces that expand to fit a full browser window, they are both very repsonsive (especially SmarterMail) and I don't believe they require a plugin?
Are these technologies suitable for ASP.NET MVC based sites?
The forum post referenced by another responder was from over a year ago, and some things have changed since then.
Since SmarterMail 7.x, Telerik was abandoned for most of the user interface controls due to some issues with the weight of the scripts and processing time to render things. Instead, custom versions of controls that render simpler HTML and script were developed to ensure things went quickly. SmarterTools still uses Telerik's radEditor HTML editing control, and the DateTimePicker control in applications, however, since they have shown to be the best option.
Charting is now accomplished through the built-in .Net Charting controls that were added in Microsoft .Net 4.0. We found then to be a suitable replacement for the Nevron Charting controls in most cases, and almost as fast.
SmarterMail does not use MVC as of version 8.x. It could be written as such, but at this point the advantages of rewriting it to be in MVC did not yield a good enough return on investment.
jQuery is the primary method of resizing and adding visual effects, and has proven to be quite effective. Most of the performance problems we ran into were related to resizing, so the order of operations when resizing had to be continually tuned.
ASP.Net AJAX with page methods is used to perform a "keep-alive" function on a regular basis that updates counters, signals the session is still active, and retrieves notifications from the server about new email, etc. Many other page functions use AJAX as well to make the pages feel more responsive and to reduce the amount of data flying around.
Grady Werner (SmarterTools)
Here's a discussion about the technologies used in SmarterMail:
We use components from Telerik for the
Splitters, treeviews, editor, menus,
date/time pickers, panelbars,
tabstrips, and popup windows. With our
own custom skins and a lot of hacks
for efficiency. Though I think someone
at telerik spies on us because every
time we hack in an optimization, they
follow suit in their next version
The grid is our own control. Other
than that we use asp.net ajax and
jquery and thats it.
And because your question was tagged with asp.net-mvc-2, you could use the same controls in your application. Telerik provide controls specifically designed for ASP.NET MVC. And jquery and jquery UI are totally server technology agnostic.
I have read several other posts here, so i get the idea on the pro vs. cons, especially having full control over the rendered html code etc. (in MVC).
My question is regarding the UI controls: In MVC, i will have to write all UI controls myself (or the html equivalent). Now is that not going to be very difficult?
The reason why these 3rd party vendors for asp.net are there is just because of the fact that it is difficult to write UI controls for ASP.NET all by ourselves, and be able to target to all web browsers, and also that we are better off concentrating our time on the business logic rather than spending the whole lot of time writing the UI controls HTML code ourselves.
I understand that this feature gets us the full control over the final html, but is it not counter-productive to do this UI bit ourselves. If it was so easy to write them ourselves, how come these 3-rd party vendors are all living now. We could have done this all by ourselves all these years of WebForms days.
I am sure i am missing something here or being a little stupid, but please enlighten me as to what i am missing in specific regard to the UI bit being written by ourselves.
Just because i get full control over the program by writing in IL code, do we go and do that? We still use C# and things like that - So that theory of "having full control over html" - i am not bought into that idea.
Please help in getting my head around this UI bit.
Other things i understand, about the separation of concern, TDD based development possible with MVC etc.
But why would i go around writing the UI controls all by myself - it is a bit a work isn't it?
The thing is:
If you want to master in web development you have to master HTML + CSS + Javascript
And with WebForms you have to learn the WebForms way to do it, but with MVC you have the power of .Net with the freedom to generate the HTML + CSS + Javascript you want.
Here's a new rant on the subject http://www.charliedigital.com/PermaLink,guid,6dcb0333-9d70-40c7-975b-0ff4011c4661.aspx
Problem is, ASP.NET MVC is much younger product than ASP.NET. For many years 3rd party companies have been developing TONS of reusable components, and I believe that it is only a matter of time before comparable set of controls will be available for ASP.NET MVC.
If you really need very rich GUI with 3rd party controls, and you can't rewrite them in acceptable time - stick with asp.net. Altough in my opinion, MVC gives you tons of power it wouldn't be wise to spend much more time rewriting controls than you can save. If you can live without controls, and like MVC concepts - use MVC, and you'll most certainly see 3rd party solutions as soon as they'll there is growing market (maybe thay've already noticed that, I don't know) for mvc extensions.
I believe that the UI and the user experience are vital to the success of a web app. Making the page intuitive and easy to use, minimizing the amount of navigation the user has to do to get the job done, and providing effective feedback and interactivity can make all the difference between a site that users want to use and one that they avoid.
If you are trying to attract users on a public website, a pleasing appearance and excellent usability are key to building repeat visits.
If you are writing an intranet app to be used by hundreds or thousands of employees all day long -- as I mostly do -- making the UI efficient and easy to use really means a lot to your users.
So, I wouldn't downplay the importance of the UI. It isn't a nuisance. It's a key part of the user experience. I suggest that a web developer should embrace whatever tools and strategies that will get the job done. That often means coding the UI controls yourself. Or working with a teammate who likes doing that part of the work.
I recently refactored a very complex website using ASP.NET + handworked javascript to MVC + jQuery. The complexity of the code was reduced by 50%-75% and became much more testable. I replaced all the complex webcontrols I had to write (with a steep learning curve I had to overcome) with very simple HtmlHelper methods.
Don't forget, when you use custom webcontrols, you are given a very static UI by the control developer. With raw HTML, you can take advantage of styles and ui developed by the whole web industry.
Increased simplicity, decreased development time, testability, flexibility in UI... I don't want to go back.
You also have to remember that ASP.NET MVC is just the first release. I don't think there is intrinsically any reason why you couldn't have the equivalent of server controls to enable certain tasks - remember, there are many server controls that don't generate any mark-up (such as the Repeater, PlaceHolder, ListView). These type of controls could be useful in a future MVC setting, I think.
I believe that ASP.net came around when lots of developers were still used to doing desktop applications and just beginning web development. AT that point in time abstracting the details of the web with controls and post backs was a great way to get people started. At that point we weren't trying to perfect the web, we just wanted to get on it!
Now that the web has matured and we've all slowly learned about html, css, javascript and the likes we want to optimize our websites for our own needs and we don't want to depend on ASP.net Forms controls to control the fine details of our websites.
In summary, I think this is about the natural evolution of many developers from the desktop to the web
I for one, am very thankful that you cannot use ASP.NET controls in MVC.
Controls, as many have already pointed out, are just server side blocks of code that render HTML and javascript on your behalf. Things like a datagrid are great, until someone asks you to make a slight modification, like having a delete confirmation alert, and then it seems impossible to do certain tasks.
The good news is that there are very powerful jQuery tools written to help you. jQgrid is a great grid replacement that does WAY more than the ASP.NET grid...
http://www.trirand.com/blog/
jsTree is a treeview that is fantastic. Again with the jQuery....
http://www.jstree.com/
And the truth is that most things you can do with razor, HTML, javascript and CSS. It's so simple that it's just stupid.
It's hard for people like myself who were web forms developers to grasp MVC and why you should use it because it's so simple. It's difficult to let go of the complexity of conventional ASP.NET. But it feels so good when you do.
And don't mix web forms with MVC. You can do it, but you will wish you hadn't.
Here is the key thing that I think you are missing. When ASP.NET is no longer the MS way of doing things...you will eventually be forced to move on and do something else. I have programmed in perl, ASP classic, then ColdFusion, then PHP, then ASP.NET web forms, then ASP.NET MVC...the only thing that they all have in common is the underlying database, design patterns, best practices for a given set of technology AND...HTML, JavaScript, CSS, and Photoshop.
No one is asking you to learn MVC. No one is telling you to not use WebForms. However, complaining that you have to write a raw UI is not going to get you very far in this industry. You should be learning something new every day...and it sounds like some time spent on HTML and CSS would be a great place to start your focus!
The biggest problem you have with relying on third party controls is when a client asks you to do something that the third party controls don't cover. If you can't replicate their complexity plus the added feature request on your own you are skirting a possible failure in your professional livelihood! You will need to know how to do it all...eventually!
I generally suggest that you embrace new technologies. You don't have to use them...but you should at least know how. This way you will know what the best tool is for any given project.
I've been wondering - what's an equivalent of 'control' from webforms in asp.net mvc? It's not a partial view for sure. What else it can be? Controller + partial views via partial requests?
Maybe i'm dumb, blind or both, but i haven't seen any 'control' for asp.net mvc. Just a lot of code snippets to accomplish one specific thing or another.
I believe that asp.net mvc is quite unfriendly with rapid development. Only way out of this problem - a lot of open source code (like MvcContrib), tutorials, sample applications & most important - slightly smarter developers.
You do not have to replace Webforms controls with something else from MVC. Just mix them - http://www.hanselman.com/blog/PlugInHybridsASPNETWebFormsAndASPMVCAndASPNETDynamicDataSideBySide.aspx
Well, I was also wondering how to use 3rd party controls in ASP.NET MVC. Obviously, and contrary to some answers here, it had to be possible.
As much time has passed since the question was asked, the industry has evolved. So I've searched and found (but havent' yet tested) solutions such as Telerik Extensions for ASP.NET MVC .
I'm posting this answer here mainly to support other MVC newbees such as myself - Just Google
"asp.net mvc" controls
I've seen a few blog posts and tutorials overviewing mixing in jQuery and the UI elements for Views in a .NET MVC web app. But usually targeted at developers with a comprehensive grasp of the full dev cycle and variations of back/middle tier technologies.
As the front end developer I'm pitching a jQuery-only UI to the back-end dev - he cautions against a non-webforms interface for sake of the code maturity pov.
I'm trying to hit back with "well...it's your pattern ...isn't it elemental to MVC? No logic in the view? I'm reading that to be 'server-side stuff'. You just serialize the properties i'm asking for, or better...let me easily discover what you _can send me...i'll be able to implement the UI via jQuery UI."
So how valid is my position?
Can jQuery's grid be expected to handle at least the bottom 85% of .net's native control (low-to-moderate capacities # of rows)?
How about in-line editing? ...from the grid?
Would working exclusively in Web Services simplify his life at all? and if so, wouldn't that be logical way to build a .net-to-jQuery relationship? - ajax liaisoning twixt server (.net WS methods) and client?
mny thx
--steve...
Don't fight the platform. That way lies pain and suffering.
The MVC view objects are vastly different than asp.net webforms with server controls--you get straight up html. You get jquery and ajax basically for free, with (almost) magic server side ajax call processing.
They are designed to do what you ask. Writing your own jquery ui is reinventing the wheel.
Not only would it be a ton of extra work for no gain. You would be the only developer around trying to do that, and when you needed help, few could offer advice.
If this is an admin interface, and the client has agreed that users must have javascript enabled then I think using javascript to build widgets on the page is a better option than using the asp.net server controls. If however this is a public facing website I would argue that a pure html and css approach is much better, and then use javascript to progressively enhance the page!
Now I dont ever advocate using asp.net server controls, because they spit out poor markup and they are overly complicated to use. Instead I have been using jQuery to do the grunt work and dom querying and traversing. I also dont advocate using jQuery UI because they are missing some very essential widgets, for example no datatable, no treeview etc. I know that there are lots of plugins for jQuery but they are not componentised and therefore each plugin needs to reinvent the wheel to achieve everything it needs. Once you have included all your plugin libraries and css you often end up with a very large page footprint. Also each plugin often has a different home page and documentation that may or may not be up to scratch.
I think that the best UI library is YUI, and you can easily combine it with jQuery. Because each widget is made up from core components the overall weight of download is smaller. Also you have all the documentation in one place with 100's of working examples. Also it means working with the same set of javascript patterns across the board, so with each widget you learn more and more about the library. Hopefully jQuery UI will catch up, but personally I am looking forward to YUI 3 which for me might mean dropping jQuery altogether...
jQuery is a very mature library. It is used by thousands of people across the internet, and I dont think I have ever encountered a bug. YUI is dogfooded by YAHOO so it too is battle hardened.
One thing I did not mention to you is that I am using the default webforms view engine with asp.net mvc. I think it is still the best option as you get intellisense and also Resharper refactoring even searches your views, and the static solution anaylsis can find code errors in your views.
For building my markup I have been using MvcContrib Fluent Html but you could also checkout this article that advocated the DRY principal very well.