August 6th, 2006
It was a slow day so I decided to cross one thing off my to-do list, and that’s getting Typo installed and migrating from WordPress. I’ve been looking at getting Typo installed for awhile ever since I saw (and liked) its AJAX-y comments form, plus Typo 4 being just released did help.
The install went straightforward enough, though I didn’t get to try out the new installer gem. I didn’t bother because I’m on a Dreamhost shared hosting account, though installing the gem without root privileges seems like it should work. I simply followed this guide to getting Typo 4 running on Dreamhost. Ran into some trouble running the Wordpress import script (found in /db/converters/wordpress2.rb), but Google turned up the solution (basically a patch to the Articles model that tries to send pings when importing posts). This should already be fixed in Typo SVN, but it’s not in release 4.0.
Anyhow, Typo seems spiffy, though I am still getting the occasional “Application Error”, but that’s most likely a Dreamhost thing. Liking the near-minimalist theme as well - I’m already missing the green clover though heh.
Things I’m already liking:
- Sidebar modules that you can add to your blog - for example, getting the del.icio.us links I have at the side to show is just a matter of dragging the del.icio.us sidebar item to the “Active” list and pointing it to my del.icio.us feed. There’re sidebar items for Flickr, tags, 43things, Amazon, and even the categories and archives are sidebar items.
- A Blacklist section where you can enter blacklisted words and regexes! Take that texas holdem poker!
- Live preview of your posts as you type - can get a little sluggish though.
- The ability to search and delete all comments - Wordpress was missing that and running SQL statements in phpmyadmin stopped being fun.
- The nice Scribbish theme that comes with the Typo package.
Things that I don’t like:
- Linking to uploaded files was confusing. I like the whole “Attachments” idea, but I didn’t know how to link to them until I browsed to the Resources section and copied the link to the image I just uploaded (by saving the post I was making - there wasn’t a way to upload an attachment while writing the post).
I’m probably doing things the wrong way though, seeing as this is way too obtuse. Would be nice to see improvements (such as, upload file as you write your post, click on uploaded file to include into post, all on the same page with AJAX).
- Um, nothing further!
Need to use it more to decide whether I’ll like this or not.
RSpec: Behavior Driven Development framework for Ruby. It’s like writing your specifications in English that’s executable. Eight tools in one, and a really nice Mock Objects framework. (0)
August 1st, 2006
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!
Comments and TrackBacks (0) | Category: Blogging, Ruby, Ruby on Rails 
