Small width layout Medium width layout Maximum width layout Small text Medium text Large text
     Search
Downloads Downloads Directory Directory Forums Forums Forge Forge Blogs Blogs        Marketplace Marketplace Careers Program Careers
Products › Development › Forge › Component - Client API Register  |  

 

dnn_ct_clientapi_170x64.gif

 
  Quick Links  
 


  Team Leadership  

Jon Henning

jonhenning.jpg
 


  DotNetNuke Projects  
The DotNetNuke Projects are a special category of platform extensions which are developed by volunteers to conform to the high professional standards mandated by DotNetNuke Corporation. The DotNetNuke Projects are distributed as a standard part of the DotNetNuke core application release offerings.
 


Maximum ASP
  Ads  
Active Modules -- Active Forums for DotNetNuke
 


  Sponsors  

Meet Our Sponsors

DataSprings - Great Ideas. Always Flowing.
R2integrated - formerly bi4ce
Jango Studios - Skins, Modules and Hosting for DotNetNuke
eUKhost.com is commited to offer exceptional UK Windows Web Hosting solutions with quality 24x7 technical support.Our plans support ASP.Net, ASP, ASP.NET Ajax extensions, XML, MSSQL, MySQL, PHP,DNN, multiple domains and Shared SSL as standard.
SmarterTools
The Official Microsoft ASP.NET Website
 


DotNetNuke® Project :: Client API

Introduction

The DotNetNuke Client API is composed of both server-side and client-side code that works together to enable a simple and reliable interface for the developer to provide a rich client-side experience.   The following diagram outlines the current consumers utilizing the DotNetNuke ClientAPI, along with the intended consumers of this functionality in the future.

ClientAPIOverview.jpg


Goals

  • Provide a consistent means of communicating information between the client-side script and server-side code.
  • Allow for functionality to easily be turned off and resort to the less-efficient way of responding to client-side events- post-backs.
  • Provide a uniform, cross-browser API that the developer can program against to provide a rich UI.  This includes but is not limited to accessing the Document Object Model (DOM), Dynamic HTML (DHTML), eXtensible Markup Language (XML).
  • Allow for the API to be enhanced and extended by both the DNN Core Team members and Third Party developers.
  • Provide ability to easily create Unit Tests to assist in development, testing, and troubleshooting of the API.  The tests should be easy to copy to any platform (windows, linux, Mac, etc.) and run, providing output that can then be sent to the developer for troubleshooting.
 


Client API Project Blog

DotNetNuke And Atlas Partial Rendering

Apr 18

Posted by: Jon Henning
4/18/2006

I have been spending most of my time lately working on coding the DNNMenu, which explains the lack of time spent blogging, among other things.  However, I did want to post on some research I recently did regarding the use of Atlas inside DotNetNuke.  Now that Atlas has a go live license I considered a few options for integrating it into the DotNetNuke core.  Namely, the idea of enabling our modules to take part in partial rendering.  If you are unfamiliar with what partial rendering does, let me briefly explain.

Partial rendering is a cool idea that Microsoft came up with to enable an area of your page to perform an asynchronous (AJAX) call to the server, posting the entire page and having the server handle the post as if it was a normal postback.  Due to a custom header posted to the server, the Atlas runtime intercepts this post and adds event handlers to deal with it in a special manner.  Before the request's content is rendered back to the client the Atlas runtime steps in and strips out all HTML not needed for the panel to successfully update itself.  Note, that this includes some of the header info and ViewState.  Once finished, the Atlas client-side script receives the html and inserts it into your panel and also automagically updates the changed ViewState.

I figured this functionality could be incorporated into DotNetNuke to allow for modules that rely on postbacks to become AJAX enabled and therefore provide a better overall user experience.  Please don't misinterpret what I am saying.  I do NOT think that partial rendering is the best solution.  Using it still requires the entire page to post back to the server and also causes the webserver to process the entire page.  It is only in the response from the server that payload is minimized.  In addition to the decrease in payload, the user does not see the flicker of the page, since only part of the page is updated.  A better solution would be to change the modules to do their own highly specific AJAX calls to retrieve only the necessary data.

So, why bother with partial rendering at all? 

The amount of time and effort involved in recoding all the modules is not practical.  If we can offer a solution that offers some of the benefits of AJAX without great cost it is worth considering. 

Are there any concerns?

1)