Two Way Bindings in JavaScript

jQuery Templates are fantastic! They provide an easy way to render your data from JavaScript to HTML.

I’ve written a simple jQuery.tmpl() implementation on JSFIDDLE to show the basics.

It is also easy to use nested templates to simplify rendering and to repeat the template over the contents of an array. Another example displays a nested template using an array of objects.

jQuery Templates also provides a mechanism for updating the data that is rendered out.

However, this feature has a problem. In this sample, I have made the “update” button dynamic using jQuery. But go ahead and click it and see what happens. It loses the cool styling and hover events. Why? Because jQuery.tmpl re-renders it’s templates and REPLACES the version on the page with a new one when you call .update();

So, jQuery.tmpl doesn’t keep the connections to your cool UI Widgets. That’s a hassle, but not too bad.

It does get bad when the user starts interacting with your template-rendered HTML. Imagine a page where there is a list of items, that can be expanded when the user wants to see details. Imagine also that the user can enter information into fields for each item. Then the user hits the sort button.

BAM! The template gets re-rendered. All the user’s expansions are lost. All the user’s entries are lost. AND you still have to reconnect all your widgets. Nasty.

Now, here’s my advice. When you have a programming problem that’s all nasty and thorny…don’t write code! Programming is easy because there are people much smarter than us that have already written the solutions for most problems.

Templates have a problem. jQuery doesn’t fix it. I’m sure somebody else has solved this problem. Let’s find them.

Today the answer is knockout.js by Steve Sanderson.

Our problem is that while jQuery.tmpl makes it easy to go from JavaScript to HTML, it does nothing for going from HTML to JavaScript. Knockout encapsulates jQuery.tmpl and extends it to provide the full round trip.

Read the excellent documentation, check out the live samples, and listen to Steve’s interview with Scott Hanselman

I’ve made the ‘Hello World‘ sample from the Knockout.js site available on JSFIDDLE, go and play with it a bit, and see what you can make it do.

Single Responsibility Principle

On the day I was born, the Egyptian military surged across the Suez Canal with 100,000 men and 1,350 tanks into the Sinai Peninsula. Simultaneously, the Syrian army sent 800 tanks into the Golan Heights. This simultaneous attack against a surprised Israel led to an amazing conflict over the course of the next several weeks that changed the state of affairs in the middle east.

At the time this was happening, Robert C. Martin (“Uncle Bob”) had already been in the software business for three years. Today, he is still a practicing programmer, working with code every day, and extending his knowledge of the art and skill of modern software development.

One of Uncle Bob’s largest contributions to our understanding of object oriented programming is a set of principles known as SOLID, which I’d like to share with you.

Today, I’m going to talk briefly about the Single Responsibility Principle, which is the ‘S’ in SOLID. This principle is very easy to remember. It simply states that any class that you write should only have one reason to change. We frequently change our classes after we write them, because the customer changes directions on us, or because our understanding of the technical requirements change.

Where we get into trouble is that our classes have too many things in them. Changing one thing causes a change to something else. Changing one thing requires us to re-test something else. Changing one thing requires us to change things somewhere else. We create extra work for ourselves. We create extra bugs for ourselves.

The Single Responsibility Priniciple is a discipline which can keep us from creating extra, unnecessary work for ourselves. By writing our code more simply, in smaller chunks, we can insure that WHEN change comes, it affects the smallest amount of code possible.

Uncle Bob’s book chapter on the Single Responsibility Principle provides a deeper view into the subject.

The CSLA of the Maltese Falcon

She sat down in my office, batting those beautiful blue eyes behind little girl glasses.Her only makeup seemed to be a bit of lip gloss that made her thin expressive lipsshine as if moist and waiting. “Rockford Lhotka isdead, and I need you to find out who killed him!” she said, a bit breathlessly, fingeringthe Microsoft logo on the form-hugging knit polo shirt she wore over her waifish figure.Her mousy hair and shy expression made clear she was the geek girl they’d all havea crush on, come the next product launch. I took the case, accepting a free copy ofVista Ultimate as a retainer.

My old buddy Lt. Hamilton, down at the eastern precinct was no help at all. He toldme that Rocky Lhotka, wrote the code and the documentation for CSLA. “What’s CLSA?”I asked.  “The primary goal of CSLA.NET is to enable you to build a rich, powerful, and flexible business layer foryour application.” Man. The L.T. can be a dick when he’s hung over. Talk English man!I took off, rather than listen to more marketing-speak from that hack.

Luckily, Maggie, who works in the stacks down at county record-keeping knew more.“What does CSLA .NET do? What doesn’t it do, honey.”

“Make it simple for me?” I asked.

“Pay attention, and I’ll boil it down: CSLA Data Binds beautifully!I’ve worked with all sorts of objects that I could supposedly bind to my .NET userinterfaces. nHibernate objects. Castle ActiveRecord objects.Generic Lists of things. On and on. What did I get? Bugs and wonky stuff that didn’twork. Bind that puppy to a DataTable and you’re listening to big band jazz, but bindto objects and you’re singing the blues. Even the new LinqDataSource only really workswith LINQ to SQL, not the other flavors.”

“So you can’t bind your UI to objects?”

“Try it with a CSLA business object. It’s like butter. These objects work so well,so completely, that you barely need to write any more code”

“But you said it did more than that?”

“Once you have that foundation, all of the other magic that the framework does isjust icing on the cake. Thick layers of fabulous icing. The fabulous business objectsthat link automatically with your UI layer also have built-in facilities for datavalidation, authorization, and permissions. There’s a whole stack of automatic undo functionalitythat you can have almost for free.”

“Wow. That’s something. You want a drink?”

“On top of all that, is an Active Record pattern implementation and ‘data portal’which allow you to use almost any remoting technology to link between applicationlayers. The code that runs on the server and that which runs on the client is exactlythe same. Your objects move magically from one to the other. Ol’ Mr. Lhotka calledthese ‘mobile objects.’”

“Seriously. I need to go and get a beer. Maybe read the sports section.”

“Coming in the next version are better LINQ query support, data access layer standardizationwith externalized object factories, and async data access. Also coming is CSLA Light,which provides mobile objects to your Silverlight Apps. I’m excited to start playingwith these feature…we’re just waiting for the manual.”

And the light dawned. Rocky hadn’t finished the manual. A tell-all confessional likethat could keep people from buying MSDN magazine and certification manuals for months!The mousy little booth babe had killed poor Rocky, and then had the nerve to hireme to find the killer! I ran out of County Records, raced round the corner, and Iheard thunder. Light flashed behind my eyes. My knees buckled. What a sap I was!

Tune in next week when you’ll hear Rocky say, “That wasn’t me, I used a mocking framework.”