This is a continuation from my last post: Implementing jQuery ajax webservices in Dotnetnuke. At the end of that post I said that I was not sure that what I set out to do would work. However, since then I was able to prove that it can work. From now on I will be using the Ajax WEBLINKS project to demonstrate my method for using jQuery, Ajax and Asp.net webservices in Dotnetnuke in place of edit pages.
I am assuming persons reading this post are already familiar with the process of creating a Dotnetnuke module so I will not go into detailed steps for creating our WEBLINKS module. Below is a mockup of what our WEBLINKS module might look like on our Dotnetnuke website. The basic idea with this module is each tab can have its own set of weblinks with its own permissions.
Naturally, the add, edit and delete buttons will only appear for people with the appropriate permissions. Then webservice will also check the user’s role before executing ajax method calls. I could go crazy with this and add separate permissions for adding, editing and deleting then add the option for admin to approve WEBLINKS; but that would require me to create a settings interface. Unfortunately, I don’t have enough time to do all of that. However, it is possible.
Designing the database
The following image is a rough design of the table which will store the WEBLINKS. I may need to change this design later on but it will do for now.
I created a database diagram which shows the relationships between the modules, tabs and their permissions to ensure my new entity fits in the Dotnetnuke database structure. The diagram only shows keys in some of the tables because I was mostly interested in the entity relationships.
I am not sure why there is a DesktopModules and a ModuleDefinitions table. Seems like these should be one table but maybe there is something I am not seeing. The modules table is what will hold the individual instances of our WEBLINKS module. This is where the values for our ModuleID foreign key will come from. This will allow each instance of our WEBLINKS module to have its own set of links.
Now that our module and database is sketched out, it is time to head to visual studio and get our hands dirty. My next post will cover the process of creating the skeleton for our WEBLINKS module.