Jon Henning wrote
The core is definitely working through the issues that arise trying to support the MS AJAX framework. Here is a summary of what I know (and don't know) thus far.
1) ScriptManager (the component that makes all the MSAJAX functionality work) requires Full Trust to work in the bin folder. You can get it to work in Partial Trust if you install it into the GAC. Due to this issue it is going to be nearly impossible for DNN to completely integrate it into the core. Any solution that is done will more than likely need to be Optional.
Yes this is a problem (for the most hosted implementations)... my biggest concern is that if it's not fully supported (and for obvious reasons it's not that easy) that module developers will stray from it. Simply because you can't leverage some of the biggest advantages easily. E.g.:
- if you use Ajax Client scripting (which is definetly a VERY strong thing) - you would need to write 2 versions of your scripts, one is for MS Ajax and the other for uncompatible version, so normal JS... this is often not feasble, not ROI friendly... and it will come down to not using it completly
- partial updates... a little simpler, but nevertheless complicated, you need to support both scenarios... if you have Script manager you can use UpdatePanel, if not you can't... often the "framework" code needed to support this will be abandonded.
And if developers don't use it for commercial modules.... a great big piece of the pie is dropped off (so to say :))
Jon Henning wrote
2) Even if we did make it not-optional, I do not think we could distribute the dll into our zip. I may be wrong here, I am not good with legal stuff... If this is true, then the DNN install would not simply work out of the "box". I realize that some people will draw the analogy that this is just like needing the .NET framework and IIS... Personally, I don't feel that these are the same thing though.
I agree that in this version of the framework that is true... you cannot draw that analogy, but if we make it optional we can probably "survive" till the next version of .NET framework which will ship with it (although this is a pretty big decision to make)
Jon Henning wrote
3) I envision the core going the optional route. This would be done by reflection, similar to our provider pattern. I envision the core "registering" the ScriptManager on the page in a similar way that a developer registers a ClientAPI script. The reason Vladan offers a separate dll httpmodule is he did not want to modify the core, this is a good approach, unless you can officially modify the core. Hopefully this concept gives developers an idea on how it can be optionally included.
It would be good to have it possible (configurable) at installation, and at runtime (via host settings for example)... that way we would (an automatic procedure would) add/remove sections of webconfig (incl. a solution similar to my httpmodule) based on configuration, and use Ajax easily without reflection (of course counting on the concsious user which will not turn on the feature unless he has Ajax installed, or in bin with Full trust). You could also add a verfication procedure which at configuration, when the check to use Ajax is clicked via reflection verifies that it actually exists.... otherwise gives the user a proper message.
At one point I've had an idea to write a simple WinForms app which can do Ajax on/off in a DNN website (targetted site) based on verification if MS Ajax is installed or in bin (and enabled Full trust), but unfortunatly don't have time for that currently (as for many other ideas :()
On the other side... If not concious user is the way to go... you can maybe take a look at this great article from Eilon:
HOWTO: Write controls compatible with UpdatePanel without linking to the ASP.NET AJAX DLL
Jon Henning wrote
4) There is a major misunderstanding about MSAJAX that I am seeing. People are confusing MS AJAX with the Control toolkit. MS AJAX only has two or three controls included (UpdatePanel being the primary one). The control toolkit is a community project, with its own release schedule. If you think about it, you probably will see a lot of similarities to what I have created. We have the ClientAPI, which is part of the DNN Framework. MS has MS AJAX that will soon be a part of the .NET Framework. We have the DNN WebControls, that utilize the ClientAPI framework to provide advanced GUI experiences. MS has the Control Toolkit, that utilizes MS AJAX to provide nice experiences as well. Right now, DNN ships both the AJAX Framework (ClientAPI) and the webcontrols with each release. This eases the burdon of the module developers quite a bit. Not only do we guarantee compatibility between releases but we also get to distribute it. The case for MS AJAX and the control toolkit will not be so easy. Some features will be integrated into the core like version checks for modules, but it is going to be a bumpy road at best (IMO).
I'm spending too much time on this post... there is still much to discuss... just need to find the time... hopefully this info sheds a little light on the subject.
I completly agree (and can confirm that based on 20 or so mails getting asked why doesn't the Control Toolkit work with my implementation, although it is only an implementation of MS Ajax), but one thing... toolkit controls cannot work without support of MS Ajax...