« November 2008 | Main | February 2009 »

January 2009

IFrames in IE -- the shocking truth THEY don't want you to know

Remember the good old days of the browser wars? Phony user-agent detection, documents that sprouted alls and layerses and what have you? You can relive the magic by trying to muck around with IFrames.

In a previous issue, we discussed how to use an IFrame to allow pasting rich text. And, if you have an area that the user consciously selects and pastes to and then proceeds via some other user interaction, then that'll work fine. If, however, you want to attach an event handler onto the IFrame itself so the pasting logic is triggered automagically -- well, then, you're in for a world of things not working in IE.

var pasteIframe = $('pasteIframe').contentDocument || $('pasteIframe').contentWindow.document;
pasteIframe.designMode = 'on';

This is as before.

pasteArea = pasteIframe.body;
if (!pasteArea) {
   pasteIframe.write('<body></body>');
   pasteArea = pasteIframe.body;
}
Event.observe(pasteArea ....

And, yes, the HTML contents of our IFrame were perfectly valid XHTML1.1 and had a body tag and everything.

Update: why write the "body" tag conditionally, and not just do it every time? Well, Firefox will "spin" indefinitely and never complete loading if you try that. And now we know.

It's the beauty of writing cross-browser Javascript. Some days, you program, using code. Some days, you chant invocations and burn chicken feet. Today was a bad day for poultry.

Posted by Ben Walsh on January 28, 2009 | | Comments (0) | TrackBack (0)

gitjour, dnssd bus error

i run macports ruby 1.8.7 and tried to use gitjour. after installing, it would bus error with:

/opt/local/lib/ruby/gems/1.8/gems/dnssd-0.7.0/lib/rdnssd.bundle: [BUG] Bus Error ruby 1.8.7 (2008-08-11 patchlevel 72) [i686-darwin9]

k, so i went to that bundle and otool -L rdnssd.bundle told me:

rdnssd.bundle:
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/libruby.1.dylib (compatibility version 1.8.0, current version 1.8.6)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.1)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
that link to osx's built-in ruby didn't look right. it should be linked to my macports libruby in /opt/local/lib. so, i went into the ext dir and checked out the makefile. everything looked proper. so i just tried a sudo make clean; sudo make again and ended up with a new dnssd.bundle, which now otool reports: 
rdnssd.bundle:
/opt/local/lib/libruby.dylib (compatibility version 1.8.0, current version 1.8.7)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.2)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
much better. so, i dropped that rdnssd.bundle back into the lib dir (overriding the one that was compiled there) and now: 
$ gitjour
Serve up and use git repositories via Bonjour/DNSSD.
Usage: gitjour  [name]
list      Lists available repositories.
clone     Clone a gitjour served repository.
serve     Serve up the current directory via gitjour.
Optionally pass name to not use pwd.
awesome. i can play with gitjour now.

Posted by visnu on January 26, 2009 | | Comments (1) | TrackBack (0)

validating mysql blob lengths in ActiveRecord

In a Rails + mysql setup, one problem I've run into a couple times is sending data to mysql that exceeds max_allowed_packet.  I also have to remember to make sure my dev instance and production are configured with a high enough max_allowed_packet for whatever blob fields I might want to send.  It'd also be nice to validate that these don't get exceeded in the ActiveRecord objects:


  def self.max_allowed_packet
    r = connection.execute "SHOW GLOBAL VARIABLES LIKE 'max_allowed_packet'"
    r.fetch_row.last.to_i rescue 128.megabytes
  end
  validates_length_of :data, :in => 1 .. max_allowed_packet,
    :allow_blank => true
  validates_length_of :file, :in => 1 .. max_allowed_packet,
    :allow_blank => true

Posted by visnu on January 23, 2009 | | Comments (0) | TrackBack (0)

Prototype 1.6 is New and Improved

More of a Prototype gotcha in this instance, but ...

Prototype offers a Hash object which implements the Enumerable mixin, thus giving access to a lot of very useful methods for handling associative arrays. For Ruby developers there's the added advantage of recognizing some familiar friends -- Ruby Enumerable methods like select, partition and map will all work just about as you'd expect.

Because Hash is intended as a sort of embrace-and-extend of Javascript's native Object, it was initially designed to be used more or less the same way. You can assign a property to an Object by saying:

    var a = {};
    a['someMethod'] = function() { ... };

... and then invoke the method with a call to a.someMethod(). All well and good, and until quite recently, if you made a a Prototype Hash rather than a native Object, someMethod and the anonymous function would be a key/value pair in that Hash.

No longer. The example given in the Prototype documentation illustrates why fairly neatly -- by creating an 'each' key in the Hash, we have unwittingly (?) overloaded the .each method on which Enumerable -- and pretty much all of Prototype -- largely depends. So the decision was taken to break backwards compatibility and change the way Prototype Hash values are get and set to avoid this, and similar problems.

And here's where the gotcha gets got. There are now effectively two associative arrays rolled into one. As a Hash is still a Javascript Object no matter what, the traditional way of getting and setting values will still work, but these are applied to the Hash's "inner Object" rather than the "true" Hash key/value pairs. The typical developer, myopic and drunk on power, is still liable to use them occasionally. Worse, existing code which predates Prototype 1.6 can now break very easily.

    var a = new Hash();
    a['someKey'] = someValue;
    callSomeFunction(a.someKey);

Nothing seems to have changed, and because you can easily manipulate the Object and pull the values out of it, it's easy to forget that the key/value pairs you've assigned are invisible to the Hash/Enumerable methods that you made it a Prototype Hash for in the first place! Observe:

    new Ajax.Request(url, {
        parameters: a.toJSON(),
        onSuccess: function() { ... }
    };

A sad pair of empty braces is all you get. Your Hash needs to be populated and queried via the new Prototype API:

    var a = new Hash();
    a.set('someKey', someValue);
    callSomeFunction(a.get('someKey'));

And, as it happens, that a.toJSON() is now Object.toJSON(a);.

So, while it was necessary, this is potentially a fairly painful change to the API. I've fallen afoul of it at least once -- now you can, too.

Posted by Ben Walsh on January 13, 2009 | | Comments (0) | TrackBack (0)