MooTools Plugin to uninstall Internet Explorer from any machine within network range

@authors = Author.find(:all)

render :json => @authors.to_json(:only => :name)

Oh and did I mention it wasn’t emitting valid JSON by default?

In the last few weeks, several patches to the Rails trunk have fixed all these issues (most of these patches are already on the Rails 2.0 Preview Release). JSON serialization of ActiveRecord objects is finally on par with XML serialization, and that old Jsonifier plugin I wrote can finally be sent off to the plugin retirement home (though, I am thinking of porting all the JSON patches into Jsonifier to add Rails 2.0-like JSON serialization to Rails 1.2.4, but who knows, I am lazy).

Anyway, back to the new JSON stuff on edge Rails.

No more invalid JSON from Rails

Yes it’s true. No more changing of module attribute to get Rails to produce valid JSON. Thanks to Choon Keat with his detailed SVN history snooping, we finally managed to get a patch to fix JSON encoding to quote all hash keys into Rails.

:include option can be used to include associations with ActiveRecord::Base#to_json

At DHH’s urging, I submitted a patch that added the :include option to ActiveRecord#to_json. Of course, it was a sloppy first submission and DHH pointed that out – a little bit of DRY love and it was really great to see it get committed (I have a soft spot for JSON serialization from Rails, since I’d been trying to achieve the same thing with Jsonifier).

So yes, now you can do:

json = @david.to_json(:include => :posts)
# or even...
json = @david.to_json(
  :include => {
    :posts => {
      :include => {
        :taggings => {
          :include => {
            :tag => { :only => :name }
          }
        }
      }
    }
})

Enumerable#to_json and Hash#to_json now accept options

One problem with Jsonifier that I often get emails about is how the to_json options don’t work for lists (Enumerables). And why is this important? Well, we often retrieve collections of ActiveRecord objects at a time with AR::B#find so it’s not too much to ask to be able to do this in your controller actions:

@authors = Author.find(:all)

render :json => @authors.to_json(:only => :name)

But of course you couldn’t, so I patched away by changing the to_json methods of Enumerable and Hash (and other types as well) to accept an optional options argument. Enumerables will pass on any options it receives to its elements. Hashes will respect :only and :except (as well as passing on the options to its elements).

Unambiguous (non-US-centric) dates and times

While Rails 1.2.3 (and 1.2.4) never supported encoding of Dates, Times and DateTimes, edge Rails has been happily supporting Date, Time and DateTime conversions to JSON since revision 6673. Unfortunately, the date string format is in MM/DD/YYYY format:

Time.now.to_json
=> "\"09/21/2007 12:15:02 UTC\""

Geoff Buesing suggested that Rails should change this to the more unambiguous YYYY/MM/DD format. Finding the right date format is important not only for readability reasons, it’s also important that the date string is directly parsable by the many browser JavaScript implementations using the JavaScript new Date(dateString) function. There is no formal spec of how dates should be represented in JSON, but it’s most convenient that strings representing dates can be directly converted into JavaScript Date objects.

Testing in several browsers and on different platforms, albeit not extensively, we settled on the %Y/%m/%d %H:%M:%S %z (strftime) format (more details in the comments of the Trac ticket).

Now it is:

Time.now.to_json
=> "\"2007/09/21 12:15:02 +0800\""

Much better.

What’s left?

Documentation, for one thing. ActiveRecord::Base#to_json is still undocumented (docfix patch). The to_json methods for Enumerable and Hash need documentation as well (will patch that soon).

ActiveRecord::Base#to_json also doesn’t deal with binary attributes, which can be easily resolved by Base64-encoding them (patch coming soon, it gets slightly complicated when trying to do a from_json). And of course, optimization improvements are always nice (decoding from JSON especially).

So, if you use JSON at all, please come in and help patch the remaining bits before Rails 2.0 rolls out. If you can’t (or more realistically, don’t have the time to) patch Rails yourself, do help out by verifying patches :).

So it is with mixed feelings when I discovered a couple of days ago when DHH committed a changeset that added a native ActiveRecord#to_json method. Of course, I’m elated that JSON serialization is given first class attention now, since the raison d’être of Jsonifier and my Rails patch was to do just that. A little bit of me is selfishly disappointed since it means that Jsonifier has become quite obsolete!

But it is an excellent change, I look forward to patching it up (if DHH doesn’t beat me to it – there’ve been so much activity on the Rails trunk recently) so that the JSON serializer supports an :include options for including associations much like for ActiveRecord#to_xml and Jsonifier’s mixed in to_json.

Update: I’ve submitted a patch for adding :include to ActiveRecord#to_json. Please test it and give feedback or +1 ;).

This would be awesome for loading heavy scripts later and only when they are “activated”, like Google Maps (which was exactly what I was trying to do earlier before realizing I’d need to setup a reverse proxy to workaround the cross-domain problem).

Oh, and the easy way to turn off browser caching in AJAX calls is a nice convenience as well (no need to append random numbers or timestamps manually).

Yup, I’m in love with jQuery right now. Protoype and YUI have fallen by the wayside like Chinese first and second wives of yore.

If you’ve tried to output JSON from your Rails applications before, you’d probably have noticed how inadequate it all seems. Let’s look at the kind of output (pretty-printed for easier reading) you get from calling to_json on your typical User model:

{
  attributes: {
    id: 1,
    name: "Konata",
    awesome: true,
    created_at: "07/01/2007"
  }
}

Some of the common problems developers who write applications that speak JSON have with this are:

• The attributes part is often unnecessary cruft when consuming ActiveRecord objects as JSON.
• There’s no obvious way to control which attributes are shown in the JSON (e.g. you may want to hide private or lengthy attributes). The way to workaround this is either to write your own to_json instance method for your ActiveRecord model, or to use a Rails plugin (like acts_as_json) or a gem.
• Including 2nd (or higher order) associations is tricky (as above, you can achieve this by defining your own to_json instance methods).

Under the hood of the current ActiveRecord#to_json

The to_json method for ActiveRecord objects falls back on using that defined in ActiveSupport’s JSON classes. The way it’s currently done, there are a bunch of JSON encoder classes defined for various types – when you call to_json on an ActiveRecord object it simply uses Object#to_json.

By the way, see that created_at: "07/01/2007" bit in the example above which is the JSON output for a Date attribute? That’s in MM/DD/YYYY format. Yup, 1st July 2007 not 7th January 2007 you “rest of the world you”. Ouch, but at least you can use JavaScript’s Date.parse() on it directly as detailed in this patch. And before you ask, yes, Date.parse() doesn’t understand the YYYY-MM-DD format.

Can has Rails patch?

So about 2 days ago, I wrote a Rails patch to boost ActiveRecord#to_json with an options hash. Yep much like what you can do with ActiveRecord#to_xml.

I hope it gets committed into the core some day. I mean, gosh, isn’t Rails all about Web 2.0 mashups. It even has that fancy render :json thing. I do believe JSON output needs to be treated more seriously in Rails rather than the half-hearted attempt at JSON encoding. No? Well, if the patch doesn’t get accepted I’ll still have my plugin (see below).

Anyway, let’s see some examples:

Some examples, see?

Assuming User and Post models where User has_many Posts:

david = User.find(1)
david.to_json  # {id: 1, name: "David", awesome: true, created_at: "07/01/2007"}

No more attributes cruft!

:only and :except work the same way that as for ActiveRecord#to_xml:

david.to_json(:only => :name)                 # {name: "David"}
david.to_json(:only => [:id, :name])          # {id: 1, name: "David"}
david.to_json(:except => :created_at)         # {id: 1, name: "David", awesome: true}
david.to_json(:except => [:id, :created_at])  # {name: "David", awesome: true}

You can use the :methods options as well to include any methods on the object.

david.to_json(:methods => :permalink)
  # {id: 1, name: "David", awesome: true, created_at: "07/01/2007", permalink => "1-David"}
david.to_json(:methods => [:permalink, :interestingness])
  # {id: 1, name: "David", awesome: true, created_at: "07/01/2007", \
  #   permalink => "1-David", :interestingness => 666}

The :include option lets you include associations.

david.to_json(:include => :posts)
  # {id: 1, name: "David", awesome: true, created_at: "07/01/2007", \
  #    posts: [{id: 1, author_id: 1, title: "Welcome to the weblog"}, \
  #            {id: 2, author_id: 1, title: "So I was thinking"}]}

:only, :except, and :methods works on the included associations as well:

david.to_json(:include => { :posts => { :only => :title } })
  # {id: 1, name: "David", awesome: true, created_at: "07/01/2007", \
  #    posts: [{title: "Welcome to the weblog"}, \
  #            {title: "So I was thinking"}]}

Of course, 2nd level (and higher order) associations work too:

david.to_json(:include => { :posts => { \
                              :include => { :comments => { \
                                              :only => :body } }, \
                              :only => :title } })
  # {id: 1, name: "David", awesome: true, created_at: "07/01/2007", \
  #    posts: [{comments: [{body: "1st post!"}, {body: "OMGWTFBBQ!"}], \
  #             title: "Welcome to the weblog"}, \
  #            {comments: [{body: "Don't think too hard"}], \
  #             title: "So I was thinking"}]}

Please do give any feedback at the Rails patch for ActiveRecord#to_json or here. I wanna know what you feel about adding this functionality into the Rails core!

Jsonifier plugin

I’ve rolled the patch into a plugin: Jsonifier. The Jsonifier Trac is at http://trac.codefront.net/jsonifier/.

Git repository:

git://github.com/chuyeow/jsonifier.git

Github project page:

http://github.com/chuyeow/jsonifier/

To install the plugin:

ruby script/plugin install git://github.com/chuyeow/jsonifier.git
 or git clone the repository manually into the vendor/plugins directory.
A note on valid JSON
The JSON Rails spits out by default is not strictly valid JSON since the JSON specifications require keys to be double quoted. To get strictly valid JSON, add
ActiveSupport::JSON.unquote_hash_key_identifiers = false
in your environment.rb (or in the Rails initializers directory if you're on edge). See my blog post on how to get strictly valid JSON from Rails for more info.
]]>
			http://blog.codefront.net/2007/07/11/better-json-output-from-rails-with-the-jsonifier-plugin/feed/
		30
		
		
		
		http://blog.codefront.net/2007/06/21/prototype-151-is-baaaaad-for-safari-1-and-2-users/
		http://blog.codefront.net/2007/06/21/prototype-151-is-baaaaad-for-safari-1-and-2-users/#comments
		Thu, 21 Jun 2007 11:15:00 +0000
		Chu Yeow
				
		
		
		

		http://blog.codefront.net/2007/06/21/prototype-151-is-baaaaad-for-safari-1-and-2-users/
		
			Read the bug fix announcement. Upgrade! This was causing extremely puzzling crashes in Safari on Macs (pre-Safari 3 beta) on one of our applications and I’m glad (in some ways) that the problem lay with the Prototype library.

]]>
			http://blog.codefront.net/2007/06/21/prototype-151-is-baaaaad-for-safari-1-and-2-users/feed/
		2
		
		
		
		http://blog.codefront.net/2007/01/28/essential-firebug-video-for-web-developers/
		http://blog.codefront.net/2007/01/28/essential-firebug-video-for-web-developers/#comments
		Sun, 28 Jan 2007 06:41:45 +0000
		Chu Yeow
				
		
		

		http://blog.codefront.net/2007/01/28/essential-firebug-video-for-web-developers/
		
			If you’re doing web development or design of any sort, you have to check out Joe Hewitt’s talk on Firebug at Yahoo! – download the movie or watch it online, just make sure you watch it.

If you aren’t already using Firebug, this will convince you. If you are, you’ll probably find some gems in there that you didn’t know before. I didn’t know that you could log events to elements on the fly, or press the up and down arrow keys to adjust numerical values (such as margins and paddings), or edit the values in the box model layout diagram, or hover over variable names to see a tooltip of their values in the JavaScript debugger, or conditional breakpoints.
Now if only it were able to detect JavaScript syntax errors that cause an entire JS file to be ignored by the browser. 
]]>
			http://blog.codefront.net/2007/01/28/essential-firebug-video-for-web-developers/feed/
		2
		
		
		
		http://blog.codefront.net/2006/08/16/beware-of-form-parameters-named-submit/
		http://blog.codefront.net/2006/08/16/beware-of-form-parameters-named-submit/#comments
		Wed, 16 Aug 2006 12:10:35 +0000
		Chu Yeow
				

		http://blog.codefront.net/2006/08/16/beware-of-form-parameters-named-submit/
		
			Well, that is if you are ever going to be submitting the form via Javascript. We had to generate forms on the fly and POST them behind the scenes (i.e. in hidden <iframe>s), and got a decent script going, until a particular case failed for no apparent reason. I finally found that the problem was due to a form parameter named “submit” that overwrote the submit() function of the <form>. That’s, of course, after looking at all the wrong places.

So this doesn’t work:
<form id="ninjaForm" action="/come/get/some" method="post">
  <input id="someParam" name="someParam"
    type="hidden" value="Some value" />
  <input id="submit" name="submit"
    type="hidden" value="Start search" />
</form>
<script type="text/javascript">
  setTimeout("document.ninjaForm.submit()", 200);
</script>
When the browser tries to execute “document.ninjaForm.submit()”, it sees the “submit” form field (which overwrote the submit() function) instead and complains that “submit is not a function”.
Do this instead:
<form id="ninjaForm" action="/come/get/some" method="post">
  <script type="text/javascript">
    // Alias the submit function in case there is a 'submit' param.
    ninjaForm = document.getElementById('ninjaForm');
    ninjaForm.__submit = ninjaForm.submit;
  </script>
  <input id="someParam" name="someParam"
    type="hidden" value="Some value" />
  <input id="submit" name="submit"
    type="hidden" value="Start search" />
</form>
<script type="text/javascript">
  setTimeout("ninjaForm.__submit();", 200);
</script>
That’s one way to workaround, of course, and we can get away with the “ninjaForm” global in this case.
]]>
			http://blog.codefront.net/2006/08/16/beware-of-form-parameters-named-submit/feed/
		3
		
		
		
		http://blog.codefront.net/2006/08/01/unobtrusive-iframe-shim-a-half-solution/
		http://blog.codefront.net/2006/08/01/unobtrusive-iframe-shim-a-half-solution/#comments
		Tue, 01 Aug 2006 11:33:50 +0000
		Chu Yeow
				
		

		http://blog.codefront.net/archives/2006/08/01/unobtrusive-iframe-shim-a-half-solution/
		
			Something that really bugged me when using YUI Calendars and YUI AutoComplete widgets was how IFrame shims are currently being managed in libraries and home-brewed code (we use IFrame shims in many places as well). YUI Calendars doesn’t have a built-in IFrame shim, YUI AutoComplete has its own, and we use our own IFrame shim library.

For the uninitiated, IFrame shims are basically IFrames dynamically inserted (hence “shim”) under overlaying DOM elements so that any <select> elements do not show through in IE 5.5 and above. A common example would be dynamically generated divs that float on top of drop downs in forms, such as the Yahoo! Calendar widget example below.





So anyway, the thing that’s bugging me is the awkwardness in inserting IFrame shims where they are needed and the duplication of unnecessary code to create, show, and hide the IFrame shims. Ideally, I’d like to do something like this to attach IFrame shims and forget about them:
var iframeShim = new net.codefront.IFrameShim(‘elementId’);
Or the conceptually nicer way of attaching IFrame shim “behavior”:
net.codefront.IFrameShim.attachShim($(‘elementId’));
No need for manually displaying and hiding the IFrame shim, polluting display logic and event handlers. I don’t care how all that shimming is done nor should I have to. I don’t want to have to call displayShim() whenever I display a floating div and hideShim() when I hide it. It should be smart enough to display the shim when the overlay is showing and to hide when the overlay is no longer visible.
As it is, I am seeing code duplicated in many places to manage these IFrame shims, and that’s a bad smell. Ahh ahh, before I go further, I am completely aware that I could be completely off-base and such a miraculous time-saver of a library already exists. If so, I want to know!
Trying to fix this problem, I came up with this bit of JavaScript, which you shouldn’t bother reading. The idea is to allow me to do this:
var shim = new com.bezurk.widget.IFrameShim(‘myFloatingCalendar’);

shim.manualShim = false;

shim.manualDeshim = false;
And I have a ‘myFloatingCalendar’ element that’s automagically shimmed whenever it’s displayed. (The shim.manualShim and shim.manualDeshim are defaulted to false, and are shown purely for explanatory purposes.)
There is one problem though – I can’t figure out an elegant way to “listen” to the display and hide events of the element that’s shimmed. The way I’ve done it is to rely on Prototype’s PeriodicalExecuter (extended to support a stop() method) to poll for the visibility of the element. Naturally this is an ugly hack and causes noticeable flicker.
I’ve looked at custom events (YUI and Dojo have very nice event handling libraries) but can’t see how to hook this up unobtrusively. If you have a suggestion or a solution, I want to hear it!
]]>
			http://blog.codefront.net/2006/08/01/unobtrusive-iframe-shim-a-half-solution/feed/
		3