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
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
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...
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 :).
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:
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.
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.
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.
nagir
Member
162 Points
184 Posts
Helpers for client-side libraries
Dec 20, 2007 01:47 PM|LINK
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:
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.
javascript helpers controls
mave99a
Member
2 Points
8 Posts
Re: Helpers for client-side libraries
Dec 20, 2007 02:05 PM|LINK
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.
jcteague
Member
211 Points
45 Posts
Re: Helpers for client-side libraries
Dec 20, 2007 02:08 PM|LINK
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
abombss
Member
575 Points
164 Posts
Re: Helpers for client-side libraries
Dec 20, 2007 02:38 PM|LINK
+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.
mdissel
Member
47 Points
16 Posts
Re: Helpers for client-side libraries
Dec 20, 2007 04:58 PM|LINK
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
nagir
Member
162 Points
184 Posts
Re: Helpers for client-side libraries
Dec 20, 2007 11:20 PM|LINK
Hello,
I think losing the WebForms functionality will have an effect. But I have 2 points on this:
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:
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:
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:
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 :)
javascript contrib licensing
abombss
Member
575 Points
164 Posts
Re: Helpers for client-side libraries
Dec 20, 2007 11:51 PM|LINK
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.
nagir
Member
162 Points
184 Posts
Re: Helpers for client-side libraries
Dec 21, 2007 01:26 AM|LINK
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.
random0xff
Member
102 Points
211 Posts
Re: Helpers for client-side libraries
Dec 21, 2007 07:58 AM|LINK
So, why not the Microsoft Ajax libraries?
abombss
Member
575 Points
164 Posts
Re: Helpers for client-side libraries
Dec 21, 2007 08:16 AM|LINK
Now its support for client script.
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.
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.
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.