Refresh

The node.js project has been getting a lot of good press and positive attention over the past few months. With good reason. If this is the first you’re hearing of node.js, it’s officially an “evented I/O for V8 JavaScript” but more generally it is used as a tool for writing non-blocking network servers. This means that it can easily be made into a JavaScript-based and highly efficient web server. If you’re curious, have a look at Simon Willison’s nice write-up.

Node is still in it’s infancy. For example, there’s is still a lot of discussion going on on the mailing list about core API (i.e. how to handle communication between and chaining of events or even how the final file API is going to look). Since node isn’t designed explicitly as a web server, there’s only low-level http support — and of course, there is no standard web application framework for handlings requests, sessions, cookies, and users.

The first question to be answered is if you’d actually want big web applications to run solely on node.js? But for now I’ve skipped that question entirely and simply asked how I’d approach writing such and application (hopefully reusing some of the code being currently being pushed by the node community)?

It seems as if every person in that community has written her or his own lightweight library for handling web requests. To name a few, there’s Djangode, Express, Coltrane, Vroom, and node-router). A lot of these are obviously inspired by the approaches taken by either Django or by Rails (it’s right there in the names), but taken as a whole they’re very limited in how they approach the task. Most of the frameworks are just different syntaxes for binding a JavaScript function() {} to a URL — without the modular approach taken by their more mature counterparts.

This means that you can easily use any of these frameworks if you need to write up a simple — and fast! — web app in a single file with a few hundred lines of code (in that case, I’d opt for Djangode), but you’d be stomped if wanted different, re-usable applications meshing into a single project. Benjamin Thomas has gone in designing mode in order to come up with a mini-framework which isn’t quite as mini as the ones listed above. His ambition is to build…

- The ability to bundle up a collection of controllers/views, models and templates into “apps” for easy portability and reuse.
- Smart defaults that hide a lot of the options/power/complexity. I think this is important for getting up and running quickly.
- A code base that is as small and simple as possible.
- I want it to feel javascript-like. Whatever that means.

The end result is Bomber. I like how Bomber creates simple URL routing to file-based (or rather node.js module-based) views, and how it lightly extends the core http.ServerRequest and http.ServerResponse objects. It feels almost native, but you see that enough of a foundation exists for this framework to actually include the ability to handle POSTs, sessions, cookies, multiple applications within a project and so on. There are no great ambitions where the framework will suddenly include a native XML parser (just a random example, sorry), but there’s enough room to grow and spread the webby wings a bit.

The Bomber project is very much in flux. In fact, it might even be dead since the last commit is a month old. And the entire project is build around an Action API which about to be deprecated. Hopefully to be replaced with DOJO-style, native Deferreds.

I’ve been playing around a bit by adding some extra stuff to Bomber through my own fork at github. I’ve already tweaked a little with the app structure to allow for multiple projects to be bootstrapped with different configurations from the same Bomber library, and there is some copy-paste and bug fixes in there as well. This will likely include experiments with multi-application projects, per-application media directories, cookie and session handling and templating (although I disagree with Benjamin that Bomber should include its own templating system; this could probably be left for the programmer to choose).

And now, back to Jersey Shore, bitches!

» Instant Gratification Now!

If you’ve ever visited the front page of Beanstalk you’ll know that they have a very nice inline feature tour, which scrolls your across some html content on the front page.

In a project I’ve been working on we need a similar way to browse through a series of articles, so I’ve built a very simple Prototype (and optionally Scriptaculous, if you want the animation to work) script, which makes it trivial to include such tours: feature-slider.js

For the guys at Beanstalk, if you’re reading this: To get your tour to work correctly in Internet Explorer, simply add position:relative to the overall container. I like your temporary IE hack, but still…

Using the code

To use the code, simply do this:

<style>
  #slide {width:300px; height:200px; overflow:hidden;}
</style>
<script src="feature-slider.js"></script>
<div id="slider">
  <div>First item</div>
  <div>(...)</div>
  <div>(...)</div>
  <div>Last item</div>
</div>
<script>var fs = new Slider('slider');</script>

A few real-life examples:

• The very simple slideshow
• More advanced content with manual menus
• Using callbacks to build the menu automatically

I’ve tried to keep everything simple, which means that the script doesn’t try to build navigation for you. Usually, this is where other similar carousel scripts go wrong. Instead you can use a few functions to browse the items in the FeatureSlider, or you can use callbacks to build advanced navigation:

fs.go(n): Go to a given item in the FeatureSlider
fs.next(n): Go to next item
fs.previous(n): Go to previous item
fs.first(n): Go to first item
fs.last(n): Go to last item

Initiating the code with the events arguments allows you to receive callbacks onLoad and onChange:
var fs = new FeatureSlider($('slider'), {
  onLoad:function(obj){
    alert('Loaded ' + obj.items.length + ' items');
  },
  onChange:function(obj, index){
    alert('Showing ' + index + ' of ' + obj.items.length);
  }
});

Apologetics in comments are usually a sign of the presence of design smell.

− from webmonkey