I'm planning to start a web based stock and current managament project.
I want app to be Ajax but I don't want to spend my time for client-side code.
Thus, I think to use coolite for my presentation layer.
However, before starting project I want to hear some advices about it.
Is it worth using in a big project and do you have any other advice about this issue?
This would be much better asked on the Coolite forums where you'll hear from actual users of the framework rather than people who will just knock it because it's not jQuery (sigh). IMHO, it is a pretty solid framework -- however, I've never used it in a production app. You really should spend some time evaluating it yourself -- take a day and mess around with their samples and see if you can build something simple. Ultimately only you can decide if it will work for your needs.
I'm yet to come across a javascript to asp net framework that isn't full of bugs. I'm in the process of an application rewrite and I'm ripping out the ajax frameworks and just using jquery.
I've found it simple to code, fast to run and easy to bug fix.
I can't comment on Coolite, but for my 10c I'd suggest just learning jQuery.
Way back when Coolite first came out I tried it and wasn't impressed and it ties you down somewhat so I just use Ext with .NET pure, a bit more work but will save you in the long run I think and keep you flexible to changes in both frameworks.
Related
Here's my particular situation...
I have a decent amount of experience with webforms, and I must say, a lot of it has been pretty frustrating. I like that there are lots of built-in controls, but then I discover that they don't quite do what I want, out of the box. I end up rolling my own controls (that inherit from the built-in controls), such as GridViewThatCanSortItself or GridViewThatHasASelectionColumn (these may not have been the actual names, but you get the idea). I've often wondered, while struggling mightily to build such classes, whether figuring out the often convoluted event model was worth it. My attempts to use css to style things have been frustrating as well. There are some ASP.NET controls that will result in one html tag for one set of attributes and a different tag with another set of attributes. You don't realize this until you notice your css only works half the time.
So, my brain starts to wonder, could ASP.NET MVC be the answer? Reading some of the posts on SO has basically given me the impression that, while webforms definitely has its issues, I'd only be trading one set of problems for another. It even seems like Microsoft is trying to talk me out of it:
Quote from the asp.net site (http://www.asp.net/learn/mvc/tutorial-01-cs.aspx)
ASP.NET MVC...works well for Web applications that are supported by large teams of developers and Web designers who need a high degree of control over the application behavior.
That is really not me. Most of my projects are relatively small, and I'm usually the only programmer. I sometimes need to create very custom or unusual UI's, but I definitely don't have a team of programmers who can build components for me.
There is also the issue of javascript. I have a definite working knowledge of html and css, but I can't say the same for javascript. As clumsy and bloated as they are, I've been able to do some smooth enough looking things with UpdatePanels. I'm not sure how much time I'd need to spend just learning the javascript to be able to handle even simple AJAX scenarios in ASP.NET MVC.
I'm about to start working on a relatively simple and small web app, so now would be the time to take the plunge if I'm going to take the plunge. This app will use a SQL Server Express (2005 or 2008) back-end, and I'm thinking of also trying out SqlMetal as an ORM solution. So, that's already one thing I'm going to have to learn, although I at least have experience with--and really like--LinqToXml and LinqToObject. The pages of the web app will have some data grids (some with link columns), input boxes, labels, drop-down lists, check boxes, radio buttons, and submit/action buttons. I don't foresee anything more complicated than that. There will be about six or seven pages total.
Questions:
Given my experience, how painful will it be to learn ASP.NET MVC? Will it be worth it?
I've read some earlier questions comparing webforms to MVC, so I'm curious, How has MVC evolved over the past year or so? Is there anything new that would make the learning curve less steep?
Do I literally have to write code to generate all html by hand or are there code/libraries readily available in the community to assist with the process? (I know I read something about "html helpers"--that may be what I'm asking about here.)
Any other advice?
Update
Another question that occurred to me: Is the transition from ASP.NET webforms to MVC anything like going from standard WPF (using code-behind) to MVVM? I found learning WPF itself to be pretty challenging (and I still couldn't say I really get everything about it), but learning to work with WPF using the MVVM pattern was a relatively painless transition. So, I'm wondering how similar a jump it is to go from webforms to ASP.NET MVC.
My advice is to work through the Nerd Dinner Tutorial from the first chapter of Professional ASP.NET MVC (and then buy the whole book, it's great) to get a feel for how it fits together and how it works for you. This covers most of what you are concerned about above.
You will have to get your hands dirty with regards working with raw HTML but this is no way near as terrifying as it may sound. Especially as you're having issues where Web Forms takes control.
Yes, Asp.Net Mvc might be a solution for your problems.
I would highly recommend you not to rush
(without better knowledge you will end up at disappointment).
But in either way - it definitely be worth it. You will learn a lot.
Start with bunch of sample applications while reading some books (start with Sanderson`s, continue with Mvc In Action). Familiarize yourself with asp.net mvc. It demands different way of thinking about web development you are likely used to. And don't be afraid of 3rd party tools - get used to them because asp.net mvc does not focus on 'ready 2 drop through designer and use' solutions and lack of super cool and shiny (with awful js/html underneath) controls at start really frightens.
After few weeks of playing around with it - you will actually be able to answer this question yourself.
And that's the one and only answer that's worth something.
Personally - i prefer asp.net mvc framework and don't want to go back despite that in some cases it does take more work (i.e. - implementation of custom pagination (which can be easily made way more sophisticated than one that pagination control provides)).
Framework demands better knowledge of OOP, architecture and design knowledge, good sense of code tidiness because there is much less 'signs' that provide direction of one and correct way of doing things - they must be figured out in most cases by yourself. So - it is easier to drown in your own sh*t, html tag soup etc. if you are unsure and/or don't know what you are doing.
I kind a disagree with that statement about large developer team. This is where knowledge about OOP, 'convention over configuration' and extensability of Mvc framework comes into play. As i see it - it's way more easier (this is really really subjective) to write code that's reusable. And with features like templates (in mvc version no2) count of code lines is reduced drastically.
And learn javascript. You are missing a lot. Play around with jQuery if you haven't done that yet (greatly reduces cross-browser compability problems). Firebug plugin for FireFox is a great aid at this (for debugging purposes). AJAX`ifying your mvc website might seem awkward at first (there's a great tips in 'Mvc in action' book about this topic like form hijacking that can be used to achieve so called progressive enchancement with AJAX), but once you get used to JS - it feels superb. One thing to mention - JS is quite sharp tool (if you don't drop what you know about development in .NET environment and don't use it as it's supposed to). It's easy to screw up JS code base in no time.
Another thing - there's a bunch of myths about mvc framework along those who have touched only web forms.
It is not hard to work with raw html.
It is not hard to read form values (binding mechanism is excellent and easily customizable/extensible).
I'm sure there are more. Just can't remember at the moment. :)
#DanThMan, I had the same reservations you did when I first took a look at the framework but having worked with it now for some time there is no way, given the choice, that you'd get me back into WebForms.
I also write, from time to time, small applications where I am the only developer and I thank God I stuck to the MVC framework and took the time to really learn it.
In my mind it has made programming fun again and I can now maintain sites quickly and easily which is a first.
For my money this is the way to go but it's a steep learning curve and you need time to get to really understand it. If you have the time I'd say go for it.
There's some good answers here and some good ones in other threads as well. I'll take a stab at a question that hasn't really been addressed yet.
How has MVC evolved over the past year
or so? Is there anything new that
would make the learning curve less
steep?
I made a conscious switch to MVC about 8 months ago and haven't looked back. Version 1 was stable and I began to use it on a couple of sites with the help of a couple of books and the internet of course. Resources were good back then but since I switched things have really blown up in a good way.
There are a couple of books out there for version 1 that are top notch (Steve Sanderson's - Pro ASP.NET MVC Framework and the Nerd Dinner book come to mind). And there is definitely asp.net MVC blood in the water so I imagine there will be some great version 2 books down the line.
The developer community, especially here, is excellent and it's getting better. "asp.net-mvc" is currently the 16th most used tag on this site and often has a very high amount of views per question. As of today I have yet to have a question that hasn't been answered. There's a lot of smart people looking at the MVC questions who are willing to help.
The contrib library over at codeplex is also getting better and getting some nice participation. They've done a great job of filling in some holes that version 1 has left. I can only think that this will continue to get stronger as MVC gets older.
The new features for version 2 are in my opinion awesome. I won't name my favorites as they won't mean much to you if you haven't played with MVC much but just know that the development team has listened and included a number of great enhancements for the new version. They are very actively seeking feedback and always looking for improvements. Do not expect this change anytime soon. (One day I called up Microsoft and said "Shorten '[AcceptVerb(Http.Post)]' to '[HttpPost]'" and bam, Mvc 2 was my idea.)
The point I'm trying to make is: since I made the switch I've seen things get better and better. I'm incredibly happy with my decision and I'm excited for the future of this project. Version 1 is good, Version 2 is better and I can't wait to see what 3, 4, and 5 ... hold.
And I'll leave you with this: I've now converted a number of friends from WebForms to MVC. Every single one of the them is glad they made the switch and the ones that work with all aspects of an application (C# code, html, css, javascript, data access, unit testing, etc) will never go back and are loving the asp.net MVC life.
Given my experience, how painful will it be to learn ASP.NET MVC? Will it be worth it?
Yes and yes. It will be painful and it will be worth it and here's why. You will be a better programmer for it and your skills will more easily transfer to other platforms. MVC is a very common pattern that you will find over and over again in just about every popular language.
You will be working more closely with html, javascript, and css, but that's web programming and you're better off biting the bullet sooner than later.
having worked my last few projects (prior to embracing mvc) using my own controls being rolled via the HtmlTextWriter, I actually found th transition quite straightfwd. i have to say tho', i did put it off until v1.0 was well and truly 'out there' and only made strides from aug/sept 09. i'm glad i got into it as the main reasons i had been using the HtmlTextWriter in webforms was to overcome some of the basic issues of class names and id's when using jquery. i'm not going to say that v1 is a silver bullet but it certainly just works in tandem with my mindset at the moment. as for literature, i too read the sanserson and nerd dinner books and took plenty away from them. at the same time, i also got into subsonic v3 and found a fair amount of tips on rob's site to get me going.
i seriously can't imagine having to go 'back' to the webforms paradigm as i had been looking for a way to drop the page lifecycle and controls bloat for such a long time (i had even looked at php framewirks at one point as a way out of the webforms dilema - kohana is a great little php framework).
anyway, just my scottish 2 pence worth...
merry xmas all and a happy 2010
jimi
Some developers seem to have an aversion to component-oriented programming. For others, it feels natural. If you find yourself constantly fighting the standard components, then it's easy enough to roll your own from scratch--which you would basically end up doing in MVC anyway. If you find yourself fighting the unit test model with web forms, you will find things easier with MVC.
However, MVC isn't a cure-all; there's a lot to learn. Some apps will be less complex than with web forms, and some will be much more complex.
I've found that web forms don't really gel with many developers until they deeply understand the page life cycle and use of ViewState. Until that point, there seems to be a lot of trial and error -- but it's easier to learn that than MVC with IOC, etc. As far as customizing output, it's often easier to use control adapters than to subclass the control. In case it helps, I walk through these issues from the web forms side in my book: Ultra-Fast ASP.NET.
In the end, I think it's partly a mindset thing, and which model fits the way you solve problems and think about your application better.
I still find myself hand coding Visual Studio projects more than using the variety of UI-driven menus and dialogs. For example:
web projects: hand code html/css in Source View vs dealing with the Design View / Properties Window
flushing out class files: code by hand using stuff like the prop-TAB-TAB Create Property keyboard shortcut and good ole Ctrl+[X|C|V] instead of the Class Diagram feature
Do I need to give the dialogs and menus another shot, or is this the current state of IDEs? Intellisense is the best thing since sliced bread IMO.
Steve
I'd be quite content to have Microsoft remove the design view from Visual Studio. I find myself cursing it every time I accidentally hit the button and wait ages for the broken rendering engine to kick in. This is from the perspective of a web developer mind you - I'm sure it's essential for developing windows apps.
Generally I think most of the RAD tools are not particularly useful, and in the long run end up being problematic as they're not very flexible. When developing web forms asp.net applications the listview and repeater are generally the only controls that I use. Hand coding html/css would be the preference for most designers anyway. Tools like Dreamweaver are nice initially when you're learning, but you do get to a stage where you realise you're using them as a glorified text editor.
Intellisense as you mention is utterly bad arse, and the one thing that I would miss if I switched to something like e or Textmate.
I am not a .NET programmer, and I understand Visual Studio does provide a lot of nifty code generation tools. However, I think it's rather important that a developer knows the code in his application. If you feel comfortable hand-coding it because you feel more in control that way, I don't think that should bother you at all.
Also, as someone who writes a lot of HTML/CSS by hand, I know that Visual Studio's Design View does not churn out 'quality' front end code a lot of the time.
I personally hand code html/css as well as my class definitions 99% of the time. Exceptions would be things that would be hard to hand-code otherwise (does anyone hand-code WCF proxies?)
It's all about YOU. What makes YOU more productive. What makes more scenes for YOU.
It's good to know and learn alternative ways to achieve your goal. You can give it try but if it slows you down return to the way YOU used to code.
I certainly find the the UI designer only works for the simplest of pages, and even for them only for a few design iterations. I find this for two reasons
1) When laying out a page, there are often several legitimate choices, and I don't like the choices VS makes. For instance, it will set the width of tables using pixel sizes, while for most fluid pages percentages make more sense. Nothing wrong with what it does, but for whatever reason I find myself fighting it more often than not.
2) It hard-codes a lot of style information, and even creates synthetic styles in an in-page style sheet. I'd rather have a concise and comprehensive CSS for the site as a whole, minimizing overrides on each page (or in each element!). Again, I fight it more often than not.
Well the designer for WPF/Silverlight is pretty cumbersome to use. So I pretty much hand code xaml and C#. At the moment I do not do much asp but with MVC, I would assume I would hand code that.
With visual studio having intellisense for a lot different syntaxes now, it is easier then ever to hand code, well, code. :) I mean intellisense works for C#, CSS, javascript, asp, and XML (if set up right). It is pretty easy to code now days. The youngsters have it so easy now days. They do not know how hard it was to code back in the day.
I'd say it absolutely, 100% depends on what you're writing.
If it's a basic CRUD interface for a simple database, then I'd say yes, 80% is way too much.
If it's a Web Application with plenty of JQuery UI and no persistent data source, then 80% is probably less than I'd expect.
As Vadium said, it also depends on what makes you more productive. Personally, I fly along with Intellisense, but I'm not too good on using UI tools to build an app.
I always feel dumber using Visual Studio, but I have to finish my project sometime this century to get paid.
I need to make a client able to drag and drop images into category-folders in an ASP.NET 3.5 web-app.
I was hoping that an option existed, that was almost as easy to use as the Reorderlist from Ajax Control Toolkit, and where I did not have to look into JQuery or similar handcoding.
What are your recommendations?
Similar questions have been asked before, like this 6 months ago...: ASP.net AJAX Drag/Drop? where MooTools is recommended, but 6 months is a long time in the ASP.NET/Ajax world, so maybe a better and even simpler option exists now?
Commercial components are also an option - well up to 200$ anyway.
My experience with the Reorder List in the Ajax Control Toolkit, as with many other 3rd party providers, is that most of them don't seem to be worth the effort. Definitely try them before you buy.
Unfortunately a lot of the samples/components out there are all too client-based and always seem to fall short on real-world uses and the sorts of interaction you need with ASP.Net applications (e.g. handling postback). Dragging a div around isn't that complicated, but that's all a lot of examples do. If your needs don't exactly mirror their offering try something else.
The Manning book ASP.NET AJAX in Action is a good reference on code for performing drag and drop. It uses Microsoft.Web.Preview, but this hasn't been updated in quite some time which is a worry. I have created a pretty good drag and drop UI with MS's PreviewDragDrop, it does work cross-browser, and it's pretty easy to code. Preview DLL's aside, the Manning book is great for understanding Microsofts AJAX API.
However, since jQuery is going to be shipped and supported with Visual Studio, I would recommend using it over anything else in a vain attempt to future-proof yourself.
A final piece of advice is never outsource your core competency. If this page is a core part of your offering you're better off implementing it yourself using library code like jQuery or Microsoft.Ajax rather than relying on a 3rd party component. However, if it's just a minor part of your site, then go ahead and use 3rd party controls.
Ref: My Version of Microsoft.Web.Preview.dll is 1.1.61025.0.
i have been very very happy with telerik's treeview control and use it for almost any asp.net application which needs a treeview drag and drop.
they allow free development licenses (not production though) so i guess you should give it a try. go to www.telerik.com and have a look
This is another Mootools suggestion, but you might find the Mif.Tree plugin useful. It's an MIT license. There are also code examples for each of the demos and API docs.
Robert>>
After spending 4-5 painful days of hacks, double-hacks and hacks to get around other hacks, I have come to the same conclusion as you. Especially the reorderlist from the ajax control toolkit drove me to the very edge of insanity.
It seems to me there is no real way around learning JQuery and simply doing the stuff myself. I used to shy away from doing client-side code, but with AJAX so much code has moved away from being just serverside.
JQuery has just been moved to the top of my personal study program.
Jquery has drag and drop controls.
Link
Maybe that will help...
I've been working on a project called Axial that converts MSIL (compiled C# or VB.NET) to JavaScript. There are a few samples of working code, but some common situations don't work properly. (The current release doesn't work in production mode and the SVN code doesn't work in debug mode but is much cleaner.) I've heard from quite a few people that they hate writing JavaScript, so I know the project has some merit, but I'd guess that attitude is less prevalent among the SO community.
Assume the product works perfectly and smoothly, so your JavaScript works 100% of the time and a Visual Studio plug-in makes sure you're using the product correctly. Is this something you or your organization would use? What features other than straight code translation would interest you?
That sounds very much like a .NET-centric version of GWT. I guess the questions are:
Have I understood the purpose correctly?
Do you believe you can overcome any roadblocks that GWT users might stumble over?
Is there enough benefit in having a .NET version as well as GWT to make the duplication of effort worthwhile? (I'd personally just write the Java code and use GWT, but I know not all .NET developers know Java, and you may already have common library stuff you want to port.)
Do you have any useful ideas you could contribute to GWT? :)
(Disclaimer: I work for Google, but haven't used GWT myself.)
Been done (pretty much).
I've just finished a flash project where I did the entire project in "pure" AS3, without the use of the Flex framework. I found very little written about this on the web, so I'm not sure if this is a common way to develop RIA's, or if I've jumped off the shoulders of giants and done something stupid that will bite me later.
It seemed like a good idea at the time (famous last words!), but was hoping to hear from someone who could confirm.
Thanks,
Marcus
There's nothing wrong with it. People do that every day using FlashDevelop and AS3-only frameworks like PureMVC. Doing a complex app without any framework to support may get difficult to support in the future, but should be OK if you adhere to well known best practices. Future maintainability, especially if it has to be maintained be someone else, can also be greatly improved by using common design patterns throughout your code and architecture. Barring all that, if you're really just slinging code to build something with any real complexity, you're probably screwed unless you documented every function and the overall architecture very very well. Maybe not today, maybe not tomorrow, but some day you're (or someone else is) screwed! ;)
Flex is nice if you want to create something that looks great real fast within the confines of what the Flex framework gives you.
We used to fight weird framework bugs which Adobe didn't seem to care about or took way too long to fix. So we opted to drop Flex in favor of our own UI framework and we've never looked back since.
Sounds like a perfectly good idea. Flex is really just an overlay of rapid-prototyping, and communication standards, on top of pure AS3.
What you gain in ease of development and a large library and API, you lose in streamlined, strength and simplicity.
I'm currently developing a medium sized app in Flex and although the first phase of development was a breeze, the later stages have been fraught with weird framework eccentricities.
It is definitely okay. For example, I've heard that the Issuu.com platform is not based on Flex but a custom framework.
Thanks all! I've been very happy with AS3, and like the amount of control I get, as opposed to using MXML/Flex. It's good to hear I'm not crazy!