e.g.if your URL was /spots/new_popup/37.77617617425586,-122.39735126495361

… then the Rails 2 route would look like this:

map.connect '/spots/new_popup/:coords', :requirements => {:coords => /.*/}, :controller => 'spots', :action => 'new_popup'

In Rails 3, there :requirements method has been replaced with :constraints. So the route above would be re-written like this:

match '/spots/new_popup/:coords', :constraints => {:coords => /.*/}, :controller => 'spots', :action => 'new_popup'

The general process is:

1. Install Paperclip.
2. Generate a migration to add the Paperclip-controlled image to your model. This adds a few Paperclip columns to the model’s table.
3. Update your model code to use Paperclip.
4. Update your views to use Paperclip’s method for writing the images, and Paperclip’s method for writing the fields for uploading the images.
5. Write a migration that does the leg-work of moving your images from FileColumn to Paperclip.
6. Uninstall FileColumn.

Step #5 is the most complex bit. There’s a few things that your migration has to do:

1. Rename/restructure directories where FileColumn stored images to the new Paperclip way. e.g. directory names are singular in FileColumn, plural in Paperclip.
2. Rename/move actual images to the new Paperclip-expected locations. e.g. different image styles (e.g. original, thumbnail, etc.) differ between FileColumn and Paperclip.
3. Populate the new Paperclip table columns with data about the images.

Mark shared a Gist that showed did all these, except for a couple of issues: It didn’t handle varying image styles (e.g. original, thumbnail, etc.), and it wasn’t a reversible migration. Using Mark’s migration as a starting point, I added support for styles, and made it reversible*. You can see my fork as a Gist. I hope someone finds it useful.

* The “reversible” comes with caveats: I’ve tried to write it in such a way that it will recover from a failed forward migration, but testing rolling back from every possible point of failure would be onerous. It works reliably if the whole forward migration succeeds, and the resulting DB contents and file structure match the beginning point. Empty Paperclip directories are not deleted after rolling back. You should back-up your database before trying it.

It shows you the word (in simplified or traditional characters; your preference) and displays the Pinyin pronunciation as a clue when you mouse over it. Click to see the English translation.

While the public library has its own search web site, it lacks the recommendations capabilities of sites like Amazon, or Goodreads. To make it easier to find the books I want, I wrote an extension that lets me select some text in a browser, and search for it in my public library:

It works from any web page, and is now available as both a Chrome extension, and a Safari one. (Firefox coming soon).

The Chrome version is available on the Chrome Web Store. You can download and install the Safari one from the LibrarySearch page on my site.

It even has pre-defined lists of names, sample titles, departments, cities, etc., so you don’t have to specify them all. However, you can add or customize your own lists too.

The only thing I’d like to see added is an option to generate XML with properties as attributes, instead of nodes. But the source is on GitHub, so you can tweak it as you need to.

• It had to support checkboxes for selection, independently of normal leaf selection.
• It needed to support visual tree lines.
• It needed to support drag-and-drop both internally (i.e. from one leaf to another) and externally (i.e. to drop targets outside of the tree).
• It needed to be easy to add icons to different nodes.
• It had to support large datasets. The “official” OpenLaszlo tree doesn’t support any form of lazy replication, so it was impractical.

I started with a version of opttree that was created by Adam Wolff (formerly of the Laszlo Foundation Classes and now of ShareGrove). In the meantime, that opttree got incorporated into OpenLaszlo, although it never made it into the official component set; it’s in the incubator. (Source for that opttree). In order to meet the above requirements, I needed to refactor the code somewhat to have a more reusable base class (sharedtreenode), from which I could create the various incarnations (checktreenode, dragtreenode, etc.). Mine never made it into the official OpenLaszlo distribution, although it has been widely used after it was informally released on the OpenLaszlo forums.

Anyway, that’s the background. Here’s one incarnation (checktree) in action:

I’ve finally updated this to run on OpenLaszlo 4.7; because it wasn’t part of the official distribution, it was never kept up-to-date. You can download the source for my opttree, complete with checktree, dragtree variants, as well as examples of how to add icons, and so forth. The test cases should give you a pretty good idea of how it’s used.

PuzzlePixies.com is a children’s educational site. It’s not actually a single OpenLaszlo app, but lots of little games for different age groups.

I’ve seen some of these games before (e.g. the classic card matching memory game). But there’s something about the colors and simple graphics that seemed to appeal to my 3-year-old son immediately. Maybe it’s the fact that a child’s voice introduces each game and tells you if you got the right answer?

The whole site is free. If you have kids, check it out!

MobileDataNow uses an OpenLaszlo front-end to allow you to configure data stores and mobile notifications. From the docs, it looks like it was upgraded to some edition of OL4.

In case you missed it, the October edition is still available, which covers built-in dropshadow functionality in OpenLaszlo. Check out Raju’s blog for a demo of this feature.

• Query string parameters in a GET or a POST request.
• POST parameters.
• Raw POST data.

The first two are fairly straightforward: A query string is the part of the URL that comes after the question mark. Post parameters (as name/value pairs) can be added to a POST request by calling setQueryParam() on the dataset. If the client needs to send a large block of data to the server (e.g. an XML document) that data can be assigned to a single POST parameter.

The third one is a little more complicated. Essentially, it means all the POST body. i.e. Where the POST parameters would normally live. Older versions of the Flash Player had problems with this, so it was not possible to submit raw POST data with older versions of OpenLaszlo in SOLO mode.

This isn’t an issue today. The Flash Player can submit raw post data. So if you absolutely can’t have even a single POST parameter, you can specify content to be included in the POST body by calling:

dataset.setAttribute("querytype", "POST");
dataset.setQueryParam("lzpostbody", "CONTENT");

Note that the lzpostbody query parameter is a special name that tells OpenLaszlo to use the provided string as the entire POST body. Here’s an example of this in action:

<canvas debug="true" proxied="false">
    <dataset name="ds" src="myService.jsp" type="http" request="false"
             querytype="POST"/>

    <button>Do Request
        <handler name="onclick"><![CDATA[
            var body = '<rawpostbodycontents>Hello, this is some XML.</rawpostbodycontents>';
            ds.setQueryParam("lzpostbody", body);
            ds.doRequest();
        ]]>
        </handler>
    </button>

    <handler name="ondata" reference="ds">
        Debug.write("RESPONSE:", ds.serialize());
    </handler>
</canvas>

You can download the entire source, complete with a JSP that reads and echoes the raw POST data.