Archive
Monthly
Go
|
|
DNN Blog
Sep
2
Posted by:
Jon Henning
9/2/2005
I am happy to announce that the ability to do Whidbey style client callbacks (Asynchronous Javascript And XML - AJAX) is coming in the next version of DotNetNuke. Check out the document here. Here is an exerpt from the document's sidebar.
It is a common practice to have client side script need to send data to the server. Within a web browser this is typically accomplished by either a POST or a GET. Both of these commands usually require a repainting of the page, since it is usually the form within the page that does the post, or the document’s location being changed to do the GET. Over the years, there have been many attempts to improve the interaction between the client side code and the web server. Technologies like Remote Data Services (RDS), Remote Scripting, Javascript Remote Scripting (JSRS), and the Webservice Behavior were developed to address this interaction. RDS is outdated since it relies on COM and ActiveX. Remote Scripting was introduced and was quite successful since it utilized a Java Applet to initiate the request to the server. Unfortunately, Netscape decided to not support unsigned Java Applets starting with version 6, thus making it about as useful as an ActiveX control. Additionally, the JVM is no longer being included with the Windows platform. The Webservice behavior is a very cool way to have the client-side code interact with the server, however, since it relies on a behavior and the MSXML parser, it is an Internet Explorer only solution. That leaves JSRS, which works by creating a hidden IFRAME object on the page with a FORM embedded in it that can be posted to the server. This makes it the most widely accepted standard for the interaction, since it only requires the browser to support the IFRAME object and FORM elements.
9 comment(s) so far...
Re: DotNetNuke ClientAPI Callbacks
This just too good to be true........ Great!!! Fantastic.
I really think this will open up DNN being more accepted as a small/medium business platform. Developers will be able to do so much more with custom modules and keep performance at a more acceptable level if those modules are complex
and... Thank you.
Now I can hardly wait for version 3.2
By Hooper on
9/5/2005
|
Re: DotNetNuke ClientAPI Callbacks
This is great news! I've been wondering over the last year-plus whether DNN would go the way of the xmlhttp call-backs. This will make DNN *very* hot indeed!
By dagilleland on
9/7/2005
|
Re: DotNetNuke ClientAPI Callbacks
I have read that AJAX is not stable
http://ajaxblog.com/archives/2005/05/25/synchronous-requests-bad
http://richui.blogspot.com/2005/09/ajax-latency-problems-myth-or-reality.html
http://www.jonathanboutelle.com/mt/archives/2005/09/jep_castelein_o.html
By shadis on
9/10/2005
|
Re: DotNetNuke ClientAPI Callbacks
Not sure what you mean by not stable. Lets review the articles you linked.
1) This deals with synchronous calls, which could hardly be called AJAX, since the A in AJAX stands for asynchronous. It is a known fact that the javascript that executes in the browser is synchronous by nature. By coding a synchronous call that could take some time to finish it will therefore appear to be locked up. The same would hold true for any long running javascript you have (for example write a loop that iterates a variable 10000 times).
2) Didn't review the entire article, but it struck me as odd that they are trying to pin the latency problems on being AJAX specific. The entire internet browser experience can have issue with latency. If your users will have issue with this, worrying about AJAX should be your last worry... worry about writing any internet application.
3) This article again discusses synchronous calls... my response is the same as 1)
Your post seems rather vague in nature... is there some specific question you wish to ask?
By jhenning@solpart.com on
9/10/2005
|
Re: DotNetNuke ClientAPI Callbacks
We are doing this already using DNN 2.1.2, custom modules and AJAX.NET (http://ajax.schwarz-interactive.de). Suffice to say we have had no stability problems, it works a treat and our only issue is non-compliant browsers.
Having it built-in will give us an incentive to move to DNN 3.x
By verdant on
9/11/2005
|
Re: DotNetNuke ClientAPI Callbacks
I was confused myself by the "Asynchronous" part, where I felt like you that it meant the nature of the actual RPC call. I have since come to understand from Jesse James Garrett that he meant that the RPC is happening asynchronously to the page flow. It seems from my experience that people who never did Javascript RPC before almost universally understand this to be the meaning, whereas those of us who cut our teeth on it before the Ajax name was coined assume the deeper technical meaning.
At any rate, the Asynchronous in AJAX does not mean that the RPC call waits for the response before the script continues. On the contrary, most people I've talked to would consider it loony to use a synchronous RPC call in a web page, although I do it all the time on intranets and the world has yet to come to an end.
By bashley on
9/13/2005
|
Re: DotNetNuke ClientAPI Callbacks
ComponentArt just released their latest version of controls with AJAX support and so far I'm very pleased with their performance and stability. Having now "tasted" AJAX, I immediately began to wish that DNN supported AJAX. All I can say is I'm delighted to hear this announcement that DNN's next version will support client callbacks.
This will hopefully enhance performance of applications, especially ones like mine that are becomming increasingly complex and heavy. To not have to repaint the page very time will be nice.
By databasedude on
9/14/2005
|
Re: DotNetNuke ClientAPI Callbacks
Harish Nair -
I am new to Dotnetnuke and I should say, it is a wonderful piece, however i am not new to AJAX and a combination of AJAX and DNN would be a great combination.
thanks
By nairharish on
10/26/2005
|
Re: DotNetNuke ClientAPI Callbacks
Jon,
I have an complete AJAX framework build on namespaces I am working on getting into the client API section. Email me at gleonardo@laacware.com and I can help with this.
Greg
By gleonardo on
1/5/2006
|
|