Hello,

With ASP.NET MVC  we are going to lose some of very powerful control suites (like Infragistics, DevExpress, Telerik, ComponentOne etc).
The vendors will not likely support MVC very soon.

So the best options for now is to stick with some JavaScript library. My preferences are:

• ExtJS
• jQuery
• YUI
• Protoype
  

Does somebody write helpers for these libraries, especially for ExtJS?
Some people did it for MonoRail and ExtJs if I can remember correctly.

There is lots of stuff in ExtJS to wrap in "Helpers" I think.

BTW, if somebody would consider writing such helpers, please keep in mind jQuery and ExtJs (I really like this one) are on top of the popularity :)
http://dnagir.blogspot.com/2007/12/2007-ajax-tools-usage-survey.html

Guys, what do you think about this?

Cheers,
Dmitriy.

 I wish the final ASP.NET MVC will not make us lose all of those web controls.  I believe those controls are one of the most valuable parts of ASP.NET, if ASP.NET MVC just become something like those raw MVC framework, e.g. structs, RoR, it's a terrible loss.

The best solution is to keep MVC and original ASP.NET stuff completely compatible.  

This is one of the things I plan on committing to the mvc contrib project.

My plan is to create an ajax interface mirroring whats available in Rails and then create library specific implementations.  My library of choice is jquery, so that one will be first.

 If you would like to help, email me at jcteague @ gmail.com

+1 Jc

As for loosing 3rd part controls I am nothing but happy.  Bring on more open, more powerful libraries.  The controls were really only needed to handle raising, bubbling, and posting back events in the old webform model.  With straight request/response you don't need any of that complicated stuff anymore.

 

Good idea! Count me especially for the wrappers around ExtJs. I've modified the ExtJsSharp source code  (see extension forum at extjs) to produce a c# source with the Config properties and the Events from the ExtJs javascript. That could be a start...

Thanks

Marco 

 Hello,

I think losing the WebForms functionality will have an effect. But I have 2 points on this:

1. WebForms controls still can be used in ASP.NET application together with MVC.
2. It is unlikely to be compatible with MVC.

Bad (which is actually good :-)) thing is developers should learn new things good thing is there's no ViewState+full HTML control :)

---

As for the js-libraries.

I see people really love two ones: jQuery and ExtJs.
Important difference is their licensing:

• jQuery - Dual licensed under the MIT and GPL.
  
• ExtJs - LGPL or commercial.

So ExtJs seems to be more strict in terms of licensing.
I cannot understand if it is allowed by the LGPL to sell (distribute for installation on client machines) the web site that uses/modifies LGLP library? What are the restrictions in this area?

The good thing is ExtJs can be used on top of jQuery (it has set of adapters). So both libraries can be used successfully together. 

---

I had have a look at projects like ExtJsSharp some time ago. Also there was one nice project on ExtJs that integrated Design-time support into Visual Studio. Not sure what its status is.
This is very interesting idea, but personally I prefer to write the JS by hand instead of generating by a framework. There are also some diadvantages, related to performance with this approach (script are always embedded into page, additional server load).

It's like companies tell "you don't need to know HTML/JS/CSS, just use our tools". People like this and use their tools. At the end they should learn and write JS anyway :).

Nothing against C# generated JavaScripts. Just my personal preference.

---

One more thing. Why then do we need ASP.NET Ajax? Can somebody give points why we need it in MVC apps?
I can see one: if MVC  is used together with WebForms, then ASP.NET AJAX is a good choice because of server-side integration. 

---

So, what about some survey for the ASP.NET MVC community which javascript library to contribute to?
This would allow everybody to move in the same direction.

What I'm trying to achieve:

1. Choose set of most suitable JS libraries for ASP.NET MVC.
2. Choose which one is more suitable for most people.
3. Stick MVC to this library (like RoR to Prototype).

This would probably allow people to contribute into the same project and make it much better, than people would contribute into different ones.

As for step 1 I propose to choose following libraries:

• ExtJs
• jQuery
• Prototype

As I said, the good thing about ExtJs is it can be used on top of both jQuery and Prototype. So having ExtJS, it will be easy to use one of these too.

Then I (or anybody) can create survey on step 2 and post it here (if moderators will allow).
Start new contribution project (or existing MVCContrib) based on the results.

So this way client-side library support will be under development based on people's opinion, not just by guessing.
It would be targeted.

Ok. Sorry for the long post :)

There is already some discussion going on in MVC Contrib about this.  Please feel free to make suggestions there, hopefully soon after the holiday some work on this will begin.

Thanks I see.

The work item is saying on itself. It says "Support for prototype.js, script.aculo.us?".
But lots (most?) devs want other libraries to use.

So it sounds like a good idea to make it pluggable. But it's not very easy and even the MonoRail still hasn't come with a good solution.

So I still think MVC should be sticked to one library. It's just impossible to make all of the client-side functionality generic.

The question is which one.

Regards,
Dmitriy.

So, why not the Microsoft Ajax libraries?

nagir:

The work item is saying on itself. It says "Support for prototype.js, script.aculo.us?".

Now its support for client script.

nagir:

But it's not very easy and even the MonoRail still hasn't come with a good solution.

 

I am not sure how much they tried, the original stuff was inspired by rails which was prototype.  They have added a JSGenerator so you can implement your own JS capabilities, its just most of the helpers are already tied  to the original prototype stuff.  I also have heard hammett say that he was disappointed with how reliant on prototype they are after he started playing with some JQuery stuff.

nagir:

So I still think MVC should be sticked to one library.

 

I couldn't disagree more, MS MVC in general is probably going to use AJAX.Net in some way.  MVC Contrib is going to want to give people the option to use whatever library they want.  Right now you can use Windsor, Spring, or StructureMap.  Similiarly you should be able to use prototype, jquery, extjs, or whatever.

nagir:

It's just impossible to make all of the client-side functionality generic.

 

I disagree, I think its important to think about the api and what functionality is required from helpers.  Every library, ext, prototype, jquery, can all do pretty much the same stuff just a little differently.  If we focus on giving developers helpers for the most common functionality it shouldn't be too difficult.  Anything that isn't common you probably want to be writing custom JS for by hand anyway.  We also have extension methods which MR does not.  Doing custom stuff in a different namespace is also a possibility.

My question is, what type of helpers are you thinking of that are so tied to a particular library.

 

Why not MS Ajax... Good question. I think it was originally designed to use with WebForms (even if it has lots other of capabilities).
Anyway, jQuery, Prototype, ExtJS are very mature ones and has lots of extnetions plug-ins etc. And they are open-source which brings more ability to it, more people contribute to it.

But MS AJAX should probably be considered too.
 

abombss:

MVC Contrib is going to want to give people the option to use whatever library they want

This is good idea, but there is always something "by default". Everybody can write bunch of helpers, even separate projects for any client-side library.

But it would be nice to decrease such a need providing a good "default".

abombss:

Every library, ext, prototype, jquery, can all do pretty much the same stuff just a little differently

Yes. But you also understand that they do it different ways. I don't believe it's possible to write GridHelper that would produce the grid with the same functionality for ExtJS, jQuery, Prototype.

abombss:

Anything that isn't common you probably want to be writing custom JS for by hand anyway.

Probably yes. But Helpers could just make it easier, like FormHelper does.

abombss:

My question is, what type of helpers are you thinking of that are so tied to a particular library.

All is because of losing WebForms controls. So I think about having UI helpers that would allow doing things like these:

• Grids. Filtering, grouping, sorting, paging etc. Very good in ExtJS.
• Inputs. Calendars, date picker, formated text, time picker, currency etc.
• User interaction. Modal windows, tooltips, feedback messages, progress bars etc.
• Validation.
• Consistent style.
• etc

Generally the idea is to "replace" existing suites as much as possible. ExtJS seems for me to be the closest one to large components suites, like Telerik's.

Maybe it is not about Helpers, but rather user controls... 

Regards,
Dmitriy.

Another vote for ExtJS featuring in mvccontrib, Microsoft MVC tutorials and the like. I love its BasicForm and TextField components to allow easy client-side validation. I think these rich javascript libraries are easily a replacement for ASP.NET control libraries.

nagir:

Maybe it is not about Helpers, but rather user controls... 

 

I share this opinion.  Helpers are helpers, not ServerControl replacements.

nagir:

I don't believe it's possible to write GridHelper that would produce the grid with the same functionality for ExtJS, jQuery, Prototype.

I hope to prove you wrong then... Although as noted above, I don't think a GridHelper is the correct use of a helper, but we will see.

abombss:

I share this opinion.  Helpers are helpers, not ServerControl replacements.

Ok. It sounds logical. So let's assume that we want to create server controls to "connect" functionality of client-side libraries with the server part.

What should be done for that and what are the plans in the MvcContrib about that?
I mean MVC is cool. But it's a really a bad thing to lose current WebForms controls.

Cheers,
Dmitriy.