Fluid Releases JS Api

I [previously](http://www.simpltry.com/2008/01/01/fluid/ “Simpltry » Blog Archive » Fluid”) blogged about [fluid](http://fluidapp.com/ “Fluid - Free Site Specific Browser for Mac OS X Leopard”). I said, “I would be surprised if they don’t expose a plugin framework.” I am happy to report I was wrong. They exposed a JS API, to get results like:

fluid js api

The reason a js api is better than a plugin framework, is because a user doesn’t need to build a plugin, they can simply include 3 lines of code in their app and they get custom doc badges. The latest version (.7) of fluid also added [growl notification](http://growl.info/ “Welcome to Growl!”) with fluid, which is cool. Anyway here is the 3 lines of code.

if(window.fluid) {
    window.fluid.setDockBadge("7");
}

Even if Fluid doesn’t stick, which I hope it does, this is certainly the a key to what the future of software development looks like.

[ANN] ActiveJax

ActiveJax is a [RoR](http://www.rubyonrails.org/ “Ruby on Rails”) plugin. It’s goal is to be an effective [ActiveRecord](http://wiki.rubyonrails.org/rails/pages/ActiveRecord “ActiveRecord in Ruby on Rails”) -> [Prototypejs](http://www.prototypejs.org/ “Prototype JavaScript framework: Easy Ajax and DOM manipulation for dynamic web applications”) bridge, allowing you to directly call your finders from javascript. Alright let’s see some code:

Ruby Model:

class Author < ActiveRecord::Base
active_jax
def find_by_name(n)
find(:all, :conditions => {:name => n})
end
end

Java Script

ActiveJax.Author.find_by_name("Nicholas Schlueter").
each(function(author) {
alert(author.name);
});

As you can see you just call the finder by name in the javascript.

It can also do belongs_to associations:

Ruby Model:

class Author < ActiveRecord::Base
active_jax :include => :publisher
belongs_to :publisher
def find_by_name(n)
find(:all, :conditions => {:name => n})
end
end

Java Script

ActiveJax.Author.find_by_name("Nicholas Schlueter").
each(function(author) {
alert(author.publisher.name);
});

Hold on, isn’t that pretty dangerous. It’s true, exposing your model can be dangerous. There is some security built in. Building on our previous example:

Ruby Model:

class Author < ActiveRecord::Base
active_jax :include => :publisher, :excluded_columns => :email
belongs_to :publisher
def find_by_name(n)
find(:all, :conditions => {:name => n})
end
end

Java Script

ActiveJax.Author.find_by_name("Nicholas Schlueter").
each(function(author) {
alert(author.publisher.name);
});

Hurray! The email address is no longer published to all would be spammers (bastards).

In order for all this to work you have to do 1 more thing, include the following somewhere in your html doc:

<%= active\_jax\_include %>

There is also a way to enable controller actions, but to be honest it is only partially thought through.

Anyone interested in learning more is encouraged to download the ActiveJax Sample Application and/or install the plugin and try it out.

./script/plugin install http://svn.simpltry.com/plugins/active_jax

In the future more information will be available at [http://rails.simpltry.com/active_jax.html](http://rails.simpltry.com/active_jax.html). Please be aware this isn’t production tested or efficient, I will be accepting patches and updating this as needed.

Prototype updated each

I have been using [prototype](http://www.prototypejs.org/ “Prototype JavaScript framework: Easy Ajax and DOM manipulation for dynamic web applications”) 1.6 for a while now and the more I use it the more I like it. I want to point out something that is a great improvement.

Prototype 1.5

[1,2,3].each(function(i) {
. . .
}.bind(blah));

Prototype 1.6

[1,2,3].each(function(i) {
. . .
}, blah);

Ok, that doesn’t look like much, and to some people it probably isn’t, but I like the way it cleans up the code. This is especially true when it comes to chaining enumerables.

In all fairness, I don’t think the [prototype core team](http://www.prototypejs.org/core “Prototype JavaScript framework: The Prototype Core Team”) came up with this idiom. I think this has been in [Mootools](http://mootools.net/ “mootools - home”) for over a year, but hey it is still welcome.

AssetPackager

It is a well known fact that reducing the number of http requests can drastically increase your page load times. One place where you can really make a big difference is your js/css files. In the past, I have written my own combiners, but those days are long gone. I have formally switched [dcrails](http://dcrails.com/ “DCRails.com || Making the Metrorail fun!”) to a well written, easy to use, rails plugin, [AssetPackager](http://synthesis.sbecker.net/pages/asset_packager “Scott Becker - AssetPackager – JavaScript and CSS Asset Compression for Production Rails Apps”).

This packager combines my js files together and then compresses them using Douglas Crockford’s [jsminify](http://www.crockford.com/javascript/jsmin.html “JSMIN, The JavaScript Minifier”) algorithm. In production it serves the compressed, combined version and in development it serves the files separately for easier development/debugging.

At my real job we need to be able to serve the merged files in qa. I submitted a patch which was, much to my delight, mostly applied. Simply add this to your environments.rb or a file in your config/initializers directory:

Synthesis::AssetPackage.merge_environments = ["qa", "production"]

Easy!

We’ve all got options

All my classes based on prototypejs use an options hash to change the way the widget renders or executes. It is a pretty typical approach to writing classes based on prototype. I used to do this a lot.

var Foo = Class.create({
initialize: function(options) {
this.options = Object.extend({
default1: 1,
default2: 2
}, options || {});
}
});

But that is kinda ugly, It would be nice to get those default options out of the main initialize method. Now I do this:

var Foo = Class.create({
DefaultOptions: {
default1: 1,
default2: 2
},
initialize: function(options) {
this.options = Object.extend(Object.clone(this.DefaultOptions), options || {});
}
});

I don’t know if this code is much more readable, but it does clean the cruft out of the **initialize** method. It also has two more legitimate benefits.

* Default Options are now clearly labeled as **DefaultOptions**
* If you decided to subclass **Foo** you could just over ride **DefaultOptions** to make them more semantical for your class

While this isn’t earth shattering, it should help clean up your code. The code above is based on prototype 1.6, but could easily be modified to work with 1.5.

Feeds/Syndication