It’s been awhile since I’ve made any mention of Jaxer, and for good reason. The Jaxer team at Aptana has been hard at work getting Jaxer ready for 1.0 Release. That day has come, and I’m proud the first publicly available version of Jaxer 1.0: Jaxer 1.0 RCB. As far as functionality goes, this release is pretty much feature-complete, and we just need some people to kick the tires a bit before we officially tag it as 1.0.

So, what’s new in this version of Jaxer? Quite a bit, actually, and if you’ve been using 0.9x releases of Jaxer until now, a lot has changed for you as well. As usual, Jaxer is available bundled into studio (starting with the recently released 1.2 version), as well as the usual stand-alone. Read on for a full summary of what’s new…

(more…)

That’s right kids, I’m speaking at the 6th International AJAX World RIA Conference & Expo! I’ll be giving a session on server-side javascript, and how it will make your life better, your apps cooler, and your friends jealous!

Read the full entry for details on the session, but here’s a little introductory overview (for the sake of not re-writing everything, I have just copied and pasted the announcement)…

Server-side JavaScript (SSJS) is growing in popularity fast since developers realize it can drastically simplify Web app creation by letting you use using the same technology stack on both the client and the server. While server-side JavaScript is not new - it was a part of Netscape’s vision 10 years ago - times have significantly changed with 10x faster hardware and networks, making that original vision for the Web now a reality.

In this session delegates will learn how to:

• Overcome common hurdles and pitfalls of client-side only JavaScript development.
• Speed up development time by cutting out extra server-side code and processing scripts that are no longer necessary.
• Clean up your code base by reducing (or even eliminating) the number of languages needed to leverage to accomplish common tasks (i.e. Why bother with server-side PHP scripts to fetch database results when you can do it all in JavaScript on the server? Why mess with Curl to fetch content that your JavaScript code can grab in one line?)

(more…)

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.
(more…)

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…
(more…)

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…
(more…)