Make Your JavaScript Data Model Smarter – With Object.Event

As today’s web applications continue to evolve and get more complex, it has become a lot more commonplace to keep a data model present inside of your javascript. You would then write various widgets, modules, or whatever that would get their data from the model, rather than querying some other web service independently (and if you aren’t doing this, you should!). While centralizing all your data into a nice, organized model that different parts of your code can access, it’s often a challenge to integrate an efficient way to notify the code that depends on these models when the stored data is updated. Lucky for us, Ryan Johnson has created a surprisingly small library that will allow our data model to notify anything that depends on it that it has updated (or loaded, or whatever you’d like in fact).

Before we dig in to the notifications, let’s do a little work to set up an example and some assumptions we’ll be operating under for the sake of this article. First, as prototype is my weapon of choice, that’s what we’ll be using. We’ll also be using prototype as Object.Event uses it as well! Now, let’s pretend that we have a website that has some social networking aspect of some kind. We want to display a short list of who’s currently online (say the 6 most recently active people) in some sort of side bar, and perhaps a count of the total members online in a footer element. Rather than having both these elements poll the server at some interval to update their information, let’s create a little data model that these areas can use instead.

Read the rest of this entry »

JavaScript & MySQL With Jaxer

Wouldn’t it be cool if you could work with MySQL within your JavaScript code? Think about it, you wouldn’t have to spend extra time writing extra server-side code for connecting to, querying, and parsing results, you could just write a little bit more code in your JavaScript and be done with it. Of course, we wouldn’t want any of this SQL exposed to the end-user, as that would be a major security issue, but what if that problem was solved as well? You might also raise the point that you’d still need the ability to prepare your SQL statements that take dynamic input to prevent SQL injection attacks, but if that weren’t an issue, wouldn’t that be awesome as well?

Seriously, take a look over an existing AJAX app you may have written. You’ve probably got a bunch of different functions for making AJAX calls to PHP scripts (or something similar), which process the input, and deal with the database, then return either parsed results, or results to be parsed by JavaScript. Wouldn’t it be nice if you could consolidate all that stuff into some smaller, simpler JavaScript code? Fewer files, less overhead… sounds good to me.

That’s one of the great things about Jaxer. If you’ve done any reading, you probably know that Jaxer works with SQLite out of the box, and you might be aware that it’s also able to work with MySQL, but most of the people I’ve talked to have stopped there. Aside from the above objections (which I’ll smash shortly ), I’ve also heard that they simply don’t want to learn another complex API. Well, the time for silly excuses is over, and I’m going to show you how easy all this stuff can be. I would suggest that you first set up Jaxer with XAMPP so you can follow along, but if you want to use the stand-alone Jaxer and Apache, you’ll be just fine. Let’s get our hands dirty…

Read the rest of this entry »

Ajax Activity Indicators – Make Them Global and Unobtrusive

One of the coolest things about developing ajax-enabled applications and sites is the level of interactivity that you can bring to your users. And perhaps one of the most crucial aspects of this process is adding activity indicators to your site. While a lot of ajax requests can be very fast, it’s still important to let your users know that something is happening. All too often I see people forgetting to add these indicators, purposefully omitting them because there wasn’t a good place to include them in the design, or implementing them poorly. One of the biggest omissions that I see is with live searches and auto-completion widgets, but not without good reason. Activity indicators can break up a good layout, as they can require a fair amount of page real estate. They’re also a major pain to incorporate into your apps, as you often end up writing a lot of redundant code to display and hide different indicators on different pages or parts of a page.

So, what can we do about these problems? Well, if you’re using prototype as a part of your framework, you can register global indicator functions. These get executed when there are active requests, and when the requests complete. However, there’s another dilemma with this method too: Where do you place a indicator that can potentially appear often and keep it from being obtrusive, or, even worse, not being seen as it’s placed outside of the content that’s currently in view? I had to tackle that issue this week while starting development on a new project at work. I wanted to create an indicator that would be in the same place on every page, and that I never had to write extra code to use. View a demo of the solution here.

The solution, in hindsight, seems very obvious and I can’t believe that I hadn’t come up with it earlier: Place a div that spans the entire width of the window at the bottom of the window and make it stick there when the user scrolled. Then use scriptaculous, or moo.fx (whichever you prefer) to show/hide the indicator when ajax requests were made/completed respectively. So how did I do it? Read on…

Read the rest of this entry »