By Joe Brinkman on 3/9/2012 1:47 PM

logoIn Part 1 of this series I discussed the basics of data binding in KnockoutJS. In this post, I’ll dive a little deeper in the the binding behaviors of KnockoutJS and show how you can build really responsive web apps using client side development techniques.

While data binding is an important part of KnockoutJS development, it is only part of what makes KnockoutJS so attractive. KnockoutJS is a JavaScript based implementation of the MVVM design pattern which is a derivation of the Presentation Model as described by Martin Fowler. Martin Fowler sums up the Presentation Model like this:

The essence of a Presentation Model is of a fully self-contained class that represents all the data and behavior of the UI window, but without any of the controls used to render that UI on the screen. A view then simply projects the state of the presentation model onto the glass.

As Fowler explains, the Presentation Model class should represent both the data and the behavior which are then bound to the view. Let’s dive into how KnockoutJS handles binding behaviors to your HTML.

By Joe Brinkman on 2/16/2012 10:21 AM

logoRecently I started using KnockoutJS as a key component in my web development toolset. KnockoutJS has simplified my code while also allowing me to create richer web UIs. I have always disliked the amount of postbacks I was doing using a more traditional ASP.Net development approach. KnockoutJS eliminates many of the pain points associated with ASP.Net development and lends itself to a more modern AJAX based style of development. In this series of articles I’ll discuss some of the basics of developing ASP.Net applications using KnockoutJS. In future articles I’ll walk through some of the more advanced features of KnocktoutJS and show how you can use it in your DotNetNuke development.



By Joe Brinkman on 2/1/2012 12:19 PM

ripAfter working with ASP.Net Webforms for the past decade, the time has come to move on. I have enjoyed using Webforms and I was pretty good at bending ASP.Net to my will. Having recently tried some newer web frameworks I find that I am more productive than ever before. Over the past couple of years I have dabbled with ASP.Net MVC, jQuery and even WebFormsMVP but none of them truly held my interest for long. I never felt like they really offered solutions to problems that I was worried about. Because of my involvement with DotNetNuke, and the fact that it relies heavily on Webforms, I found that I couldn’t justify the use of some of these technologies. Things like WebFormsMVP added too much friction to the way I was used to working. ASP.Net MVC couldn’t really work in any meaningful way with DotNetNuke. And jQuery was a nice add-on, but it didn’t fundamentally change the way I developed modules.

By Joe Brinkman on 10/16/2010 4:05 AM

Over the last couple of years, I have been doing more and more work with JavaScript.  Whether it is work on web pages with jQuery or work in mobile applications with Appcelerator Titanium, I often find myself needing to transfer data to and from the server as JSON.  In DotNetNuke I frequently found myself constantly converting my .Net objects to and from JSON and it seemed to be a waste of time to constantly figure out what framework I should use to handle the JSON serialization/deserialization tasks. 

I have tried the JavaScriptSerializer,  the DataContractJsonSerializer  and even JSON.Net but I always keep coming back to the JavaScriptSerializer because it is the simplest solution that doesn’t impose any 3rd party dependencies.  The problem with all of these solutions is that I am constantly having to remember how to use them.  The API, even for the JavaScriptSerializer, still requires several lines of code whenever I want to use it.  I wanted something that was drop-dead simple, yet still powerful enough to handle 95% of my serialization/deserialization needs (for the really tough stuff I can still use one off code with an appropriate serializer)

By Joe Brinkman on 8/26/2008 4:06 PM
Over the last several years web developers have moved more and more code to the browser in an effort to improve the overall user experience.  This code is usually in the form of JavaScript libraries which provide advanced functionality and improved performance.  With the widespread adoption of AJAX developers are pushing our JavaScript skills to the limits.  Even with this increased reliance on JavaScript running in the browser, there is still a need for server side application code.  While the split in application logic has brought some improvements in our user experience, it has brought its own set of challenges as well.  Having application code in two locations often requires us to pass values from the server side to our client-side JavaScript...
By Joe Brinkman on 8/21/2008 11:07 AM

There appears to me to be a recurring pattern I see on many web sites.  Often you will have a JavaScript library that you want to use which requires certain variables be defined in your web page.  I have seen this pattern repeated for many different widgets that you may want to include on your page.  [more]The pattern generally looks like this:

While this works, I didn’t like the need to create the extra script block just to set a few values.  There are some cases where the second script block is needed because you need to calculate the value, but often the values are fairly static or are calculated on the server when the page is generated.  In these cases, the extra script block should not be needed.  What I really wanted was a way...
By Joe Brinkman on 7/25/2007 8:35 AM
DotNetNuke 4.5.4 introduced native support for SSL in the DotNetNuke framework.  During the testing phase and since it's release there has been some discussion (here, here and here) about the efficiency of the DotNetNuke implementation when shifting from http to https and vice versa.  It has been suggested that using Javascript, like that shown below, is much more efficient when performing the redirect.