Most of the time cookies are handled by the server using languages like PHP or Ruby, but there are times when using JavaScript to handle the cookies is the best option. Cookies are a strange beast in JavaScript and many developers don’t know how to use them. That’s all about to change!
Mixins are a way to add the functionality of 1 or more objects to a new object, essentially creating a non-standard means of inheritance. This inheritance is also done functionally, which is the way JavaScript seems to like having things done. Basically all we’re doing is reusing functions without the need for the standard inheritance model.
We’ve made it to the final installment in the JavaScript Design Patterns series. That’s right, after this you’ll no longer have any clue what post will be coming out every Monday! Well today, we’ll be talking about the Chain of Responsibility Pattern. This pattern decouples the sender and receiver of a request. This is done with a chain of objects, each of which can handle the request itself or pass it on to the next object. Confused? Read on.
I realize the two posts per week on a blog will help give insight to many developers out there, but it can’t compare to the teaching power of a book. If anything, this blog just whets your appetite to learn even more (unless you hate this blog, in which case it’s making you wish JavaScript didn’t exist) and you just don’t want to wait several days for that appetite to be fulfilled, just to read another 700-1000 words and then wait some more. This is why I’ve decided that you should have more, so I’m doing the work of reading through JavaScript books in order to determine which ones will be best for you to read.
The Command Pattern is a strange beast in the context of object-oriented programming. Unlike most objects, a command object represents a verb, rather than a noun. This is a little less odd in a language like JavaScript where functions are actually a type of object, but the classical sense of the Command pattern is still different than a function.
If you’ve been using JavaScript for any semi-substantial amount of time, you’ve probably had to add some HTML to your page dynamically. If you haven’t then you’re missing out on some of the greatest power of JavaScript. There’s a problem though: It’s a pain in the buttocks to write HTML code inside a JavaScript string – especially when it’s a large amount of HTML and/or some of the tags have attributes – and adding in values from variables. It’s just a giant mess of quotes and plus signs.
It’s time to introduce you guys to the Observer pattern. If you’ve been following this blog lately, you may have already had an introduction through my post talking about my jQuery plugin called JZ Publish/Subscribe. Well, here we’ll be talking about a few other ways to implement the Observer pattern, so you’ll know the method that works best for you and your application.
It’s a great day here at Joe Zim’s JavaScript Blog and surely a great day for the users of the JZ Publish/Subscribe jQuery plugin. This plugin has now been updated to version 1.2 and has gained probably the best feature it could gain at this point in its life and something that, arguably, maybe should have already been included with the plugin.
If you don’t already know, JZ Publish/Subscribe is a jQuery plugin that I developed to add a simple, but powerful Pub/Sub feature to the jQuery utility functions. I’m guessing there are some people out there who don’t understand what Pub/Sub is, how to use it, or why to use it. I’m here to bring some answers and give a specific example of how JZ Publish/Subscribe can be used.
This is the 9th installment of the JavaScript Design Patterns series and today we’re featuring the Proxy pattern. The word “proxy” can be defined as a substitute, and that essentially explains what a proxy is. A proxy is an object that has the same interface as another object and is used in place of that other object. The only question is why we would use a proxy instead of the original object.