Implementing jQuery ajax webservices in Dotnetnuke.

I have been looking into Dotnetnuke for the past couple of weeks in preparation for a new client project which requires Dotnetnuke. One of the questions posed by my team was, how will we make use of modern standards such as Ajax and jQuery? I was specifically interested in the ability to make ajax calls using jquery while still maintaining our Dotnetnuke security context. I did my usual Google search and found a few examples that seemed to be going in the right direction. Then, I came across the iweblite project on codeplex which seemed to do exactly what I wanted.

This post and the next few posts will explore the use of jQuery/Ajax and and wfc webservices as alternatives to regular Dotnetnuke edit pages. In the end I should have a working module which demonstrates a secure but unobtrusive way for developers to use jQuery/Ajax in Dotnetnuke. However, At this point I have no idea if any of this will work.

I drew up the diagram belong to illustrate my understanding of the Dotneuke system and how a webservice script currently fits into the picture. The yellow tile in the middle represents the entire Dotnetnuke installation, the purple tiles at the top are modules installed by the host, the purple portal tiles are different websites hosted within the Dotnetnuke installation, the blue page tiles are Dotnetnuke pages/tabs which are essentially containers for a bunch of instances of the modules defined above.

Dotnetnuke application layout

Let us create a sample module called WEBLINKS from our illustration

Dotnetnuke separates the definition of a module from its actual placement. So Although WEBLINKS=300 and WEBLINKS=99 are of the same module WEBLINKS(defid=2), they are treated differently by Dotnetnuke.  WEBLINKS(defid=2) is designed so that each instance has its own data. This means that WEBLINKS=300 on tabid=2 will show a different set of links from WEBLINKS=99 on tabid=1.

Let us create a user called USERA and give him access to edit/view WEBLINKS=300 on tabid=2 but not on WEBLINKS=99. This means that USERA will see WEBLINKS on tabid=2 but not tabid=1. We want to make our WEBLINKS module cool by adding in some ajax functionality. So rather than the usual dotnetnuke edit page, we will allow users to add a new weblink right on the module view page. We will achieve this by using Jquery to send a JSON packet containing the details of our new weblink directly to our AjaxHandler.asmx or AjaxHandler.svc. We expect that when USERA has added his new weblink it should only appear in WEBLINKS=300 on tabid=2. We do not want him to have the ability to add weblinks to WEBLINK=99 on tabid=1. We will probably provide use a modal or slide down form for to input the new weblink.

The challenge with calling a webservice in this scenario is figuring out the context in which the request was made. This is where iWeblite comes in. It uses the request url to find the portal id (There are potential  issues with having the client provide the portalid) so all we need to get from the client are the tabid and the tabmoduleid for us to get the user’s security context. So theoretically, we should be able to make a call to AjaxHandler.asmx using Jquery with our tabid, tabmoduleid and other module specific parameters and get the same result we would from a postback.

My next post will talk about the design and basic functionality of the WEBLINKS plugin I will use to prove this concept. Again I have no idea whether or not I will fail in proving this to be a viable option for module development in Dotnetnuke.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s