home

JavaScript Design Patterns: Decorator

Today I’d like to show another JavaScript Design Pattern: the Decorator, which is a way to add features to objects without subclassing or adding extra attributes. This post continues the JavaScript Design Patterns series that I started several months ago. If you’re new to the JavaScript Design Patterns series that I’m running here, you can find a list of the previous and upcoming posts in the series at the bottom of the post.

New Projects Section

All of you JavaScript lovers out there who have been following this blog recently will probably know already that I recently released a jQuery plugin to add Publish/Subscribe functionality. The Announcement was posted just a few days ago. Well, I decided I can’t just leave the information about the plugin in a post that will fade into the ages of the archive, so I created a Projects page, which you can access via the link on the main navigation bar.

New jQuery Plugin: Publish/Subscribe

I recently started looking through Dojo because another blog writer seemed to highly recommend it while saying there’s no real need to use jQuery. Dojo seemed quite powerful, probably having DOM manipulation on par with jQuery, but only if you required the correct extra modules. Also the syntax for Dojo is far more verbose. Still it seemed like Dojo had something that jQuery didn’t, so I sought to find what jQuery was lacking. It turns out that the only thing that Dojo (excluding Dijit and it’s other separate libraries) had that jQuery didn’t was a publish/subscribe module.

JavaScript Design Patterns: Adapter

Another post, another JavaScript design pattern. This time we’re featuring the Adapter pattern. If you’d like to view the previous posts from this series, you can check out the links at the bottom of this page. This mean, green, fighting machine can transform interfaces. Ok, it doesn’t exactly transform an interface, it really just creates a new object/function that adapts the interface of an existing object/function to match what the code knows how to use.

JavaScript Design Patterns: Facade

In our 4th installment of the JavaScript Design Patterns Series, we’ll be taking a look at the Facade pattern. Whether you know it or not, I can almost guarantee that you’ve used the Facade pattern if you’ve been programming in any language for more than a second (that might be a bit of a hyperbole, but you’ll forgive me, right?). You can define the Facade pattern as a piece of code that simplifies a more complex interface. You can pretty much call any form of abstraction a facade. Have you ever made a named function that had more than one line of code within it? Yup, that’s technically an example of the Facade pattern.

JavaScript Design Patterns: Composite

My last post was about the Bridge Design Pattern, which continued the JavaScript Design Patterns series that started off with the Singleton. Today we’ve moved onto the Composite Pattern. Composites are quite useful. By definition of the word “composite”, Composites are _composed _of multiple parts to create one whole entity.

JavaScript Design Patterns: Bridge

In my last blog post article I discussed the Singleton Design Pattern and how it is used in JavaScript. This time around the Bridge design pattern is poking its head up and asking for a bit of attention, making it the second in the JavaScript Design Patterns series. Every place I’ve read about the Bridge pattern likes to quote the Gang of Four directly in their description of what the Bridge pattern is, so I figure why not me too? The Bridge pattern should “decouple an abstraction from its implementation so that the two can vary independently.” Bridges are quite beneficial in event-driven applications, which are quite common in JavaScript. Considering that fact, it’s surprisingly one of the most underused design patterns.

JavaScript Design Patterns: Singleton

This is the first in what should be a pretty long series about JavaScript design patterns. In 1995, Erich Game, Richard Helm, Ralph Johnson and John Vlissides (known as the Gang of Four) published Design Patterns: Elements of Reusable Object-Oriented Software, a book cataloging recurring solutions to common dilemmas in software architecture and design. It also started a common vocabulary for referring to these solutions. If you’d like to know more you can find it on Wikipedia.

Securing JavaScript

The ProblemCross-site Scripting is a problem in the world of the internet. Someone hijacks your web site by injecting a little bit of JavaScript code and suddenly he/she has access to pretty much anything they want on your site. Douglas Crockford gave a talk at the end of March last year (at least, that’s when his video was published on YUI Theater) that partially discussed this problem, and this article is largely based off that talk. He noted the web’s vulnerabilities to these types of attacks, mostly due to standards that must be implemented by the browsers and having very little to do with bugs. He also felt, though, that JavaScript is one the best languages for creating secure code.

Infusionsoft Failure

Has anyone here ever used InfusionSoft? It’s an amazingly powerful piece of online software that brings together a lot of features dealing with email marketing, sales, tracking, statistics, and shopping carts. There’s tons to talk about and it’d take a couple year’s worth of blog posts to go through every feature and that would only happen after the year it takes me to learn InfusionSoft. This blog post is exclusively about the shopping cart feature and the headaches that come with it.