We set up another stack for layout, and title the page based on the title of the paste. Below that comes the actual text of the paste, with a monospace font specified. Next comes a delete button, with a confirmation behind it. This will pop up a yes/no alert as a safeguard against accidental deletion. If the user agrees to continue with the deletion, we send a DELETE request to the paste's URL, and the Merb server deletes its record. We then "visit" the / pseudo-URL, which sends us back to the list of pastes.

At the bottom of the page is a "View all pastes" link that we can use to return to the list of pastes. We reuse this on the New Paste page, so we have factored it into a separate method.

In our running Shoes application, we can see the result of this page by clicking on a paste title from the main list.

The last page to show is the New Paste page, generated by the new_paste method:

By now, most of this should be familiar. Here we see a flow used for the first time to flow elements horizontally; we use this to put the caption for the "Title" box to the left of the box itself.

We assign the edit_line and edit_box (similar to HTML's <input type="text"> and <textarea> controls, respectively) to instance variables. This allows us to read their values later, when the "Paste!" button is clicked. Many elements can be updated by holding references to them like this. (Sadly, button text cannot be updated in this manner; this prevented us from writing the tic-tac-toe game that we wanted to.)

When the Paste button is clicked, we send a POST request to the server, passing the paste's information as parameters. The server sends back a data structure, and we use that to build a Shoes pseudo-URL (which corresponds to the newly created paste's show page). Here is what the completed New Paste page looks like:

Upon submitting this paste, we are redirected to the resulting "show" page:

Conclusion

By walking through both the Merb and Shoes side of Shmerboes, you've seen a whole lot of Ruby code. The beauty of this application is not that it solves a particularly difficult or exciting problem, but that it shows something a little bit different than your average web application.

Merb is already showing lots of strengths in unexpected places, and though Rails may still be king for your more conventional applications, the flexibility and power of Merb can really come in handy for jobs that have custom needs. The fact that it is lightweight and fast is quite a nice bonus as well.

Shoes seems to show a ton of promise for Ruby's GUI future. Right now, it is admittedly a little too rough around the edges in terms of stability to feel safe with. Admittedly, like all things _why produces, the creativity and the bit of 'danger' surrounding the framework are exciting, and can even be useful for certain things. A year from now, Shoes will hopefully be as fun as it is now to work with, but polished enough to do stuff that smells a bit like work in.

What we hope you've gained from this article is a basic understanding of how Ruby can be used to interoperate between different environments, and that the possibility of a GUI frontend to a web service backend is possible writing nothing but Ruby code. If you'd like to poke around a bit more and pick up where we left off, the Shmerboes code is available under the public domain. Please enjoy, and happy hacking!

Gregory Brown
is a New Haven, CT based Rubyist who spends most of his time on free software projects in Ruby. He is the original author of Ruby
Reports.

Brad Ediger
is a freelance programmer, specializing in Rails, who has used the framework since its release in 2004. He and his wife Kristen (a web designer) own Madriska Media Group, a web development firm.