Related Links

Helpers for client-side libraries

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

Re: Helpers for client-side libraries

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.

Re: Helpers for client-side libraries

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.

Re: Helpers for client-side libraries

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...

Re: Helpers for client-side libraries

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

WebForms controls still can be used in ASP.NET application together with MVC.

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 :).

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:

Choose set of most suitable JS libraries for ASP.NET MVC.

Choose which one is more suitable for most people.

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.

Re: Helpers for client-side libraries

Re: Helpers for client-side 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.

Re: Helpers for client-side libraries

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.

Re: Helpers for client-side libraries

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.