At this point in our module development series we need to take a step back from the action oriented items in code and talk at a high level about our path forward in this series. Among web developers there has recently been a trend toward more client side development. This “front-end” heavy method of development allows for very rich user experiences, faster page load times, and fewer page refreshes. In case you are not very familiar with the term "client side" development it usually means there is more JavaScript involved and is more HTML, CSS, and JavaScript centric. It’s also common that web apps that are heavy client side apps integrate with web services.
Why Opt for “Modern” – Viewstate, Postbacks, & User Experience
You may wonder why this trend has occurred. The real reason is frustrating user experiences! Though to technically speak about it one reason is that a lot of earlier written .NET applications usually contained a lot of server controls on their pages. These server controls created more and more viewstate on the page and more and more “round trips” (requests) to the server. If you're not familiar with viewstate check here for more info http://en.wikipedia.org/wiki/ASP.NET#View_state .
The more viewstate you have on a page the more "payload" the browser has to download and the slower the page loads. Often times server-control-heavy pages require several "postbacks" to the server. These postbacks equal another round trip to the server consequently causing slower load times resulting in end-users waiting longer for the page to load. Ultimately these factors combine to provide a sub-optimal user experience. Collectively the web found a way to create a better user experience and that way is full of JavaScript & web services.
JavaScript, Back Again!
Over time JavaScript has become so popular and widely used (JQuery, Knockout, & Angular libraries to name a few) that very rich user experiences are now able to be created with mostly HTML, CSS, and JavaScript. Pages load more quickly and end-users get slick and interactive experiences that are more engaging.
Even though apps are now using these front-end libraries they still need to get data from the application’s database, in our case... our module needs to get data from SQL. This is where web services come into play and, more importantly to us, the integration of Microsoft's Web API at the core of the DNN Framework. Microsoft WebAPI is a web services framework that allows us to expose data on end points that we can consume within our module and from anywhere else if we choose! This exposed data can be in many formats, but most commonly it is exposed as XML or JSON.
Sidenote: “JSON” stands for JavaScript Object Notation and if you need more info on it then check out this link http://www.w3schools.com/json.
DNN has wrapped the Microsoft Web API with a DNN wrapper that makes it easy to work with the Web API within DNN meaning that you still have access to all the DNN goodness (API’s, info, etc.) from within your module and you still get the security benefits that DNN provides.
The majority of DNN module development tutorials that you'll find online are based on the way modules were built over the past few years. Though, there are some tutorials on what is known as "modern module development" out there. Check out DotNetNuclear.com for a few examples.
I have discussed all this to let you know that at this point in the series we're going to opt for the "modern" development route in this series. If you remember from the previous blog entry about coding and designing the view I made a mental note that we were using HTML controls versus .NET server controls and this is exactly why we did it that way.
Our module won’t be 100% client-side, but the point is that we’re going to reduce the number of sever controls included in our module to as few as possible all in the name of user experience & faster load times. So we are going to expose our task data via DNN's Web API Services Framework and then we're going to grab it, serialize it to JSON, then use JQuery AJAX to bind each JSON object to dynamically created DIVs in our module (Sounds geeky huh :-) ). Now if you're a front-end developer then we're starting to speak your language and you're probably licking your chops right about now, but if all that sounded like Spanish to you don't worry, we're going to go over all of that in upcoming blogs as well.
Since we're opting for the “modern route” of module development our next step will be to create the Web API Services for our module... and we'll do that in the next blog entry. Hope to see you there!
Go to the Next Blog Entry: "Creating the Web Service Class"