gui.net - Rails Slices and Beyond

Rails Slices and Beyond Luigi Montanez posted a video of this talk, over on Vimeo, called the Russian Doll Pattern. It was hard to hear a lot of this talk, the recording is very soft [and one of the presenters talked even more softly], but the Russian Doll Pattern title appears to refer to the ability of a slice to automatically install/load dependent slices.

Slices are large plugins-like-appl... that can command their own [part of the] database and can share specific data with your application. For example an entire Blog. Or a Forum. Both require access to the user\'s information and authentication etc. as well as to their own namespace-protected part of the database server.

A few slides from the presentation are included here. Essentially here is the 30-sec version of the hour-long presentation: There are certain things one might expect to have to do to drop in a slice into their application. Here are some code snippets that show something like what we expect the code to look like that handles the glue [more or less] between the main app and slice-apps. Routes. OK. Mounting slices. OK. Some hand waving about installation [hope it is gem-like and installs things in /apps instead of /plugins, but I think I heard that it would not be?].

But the GUI. To maintain visual consistency across your app and the slices that you install they suggest treating templates like an API. To this end, they encourage people to write slices with a lot more helpers than they might ordinarily write, to treat partials as another API, and to test the slice\'s templates a little more thoroughly because this is just like a library API.

OK. So that was the presentation. Now for the \'beyond\' part.

What if one wants to be able to plug-and-play slices. What if you want to try 2 or 3 blog implementations by just changing the single \'mount slice\' line of code. What if one wants to decouple themselves from any particular blog implementation because one is really fickle and likes to change the blog slice every other Tuesday? And similarly for forum slices, cart slices, CRM slices, and calendar slices.

This requires either 1) a Standardized Slice Integration API for each vertical [more about what is meant by this below] for all, say, blog slices, or 2) for some magnanimous person to write an adapter that generalizes the API [and does some automatic porting of the database during the remounting] for all popular blog slices.

It is this common API that interests me.

On the database side we can expect all blogs to have a \'posts\' table. And a \'comments\' table. With a core set of table columns the same for all blog slices.

On the routes side we can expect there to be a blog_for_user address that is the same across slices [there are different ways to do this, but let\'s ignore that, OK? OK].

Then, on the view side of the Standardized Slice Integration API, we have...? Assuming CSS was worth its salt, we would have a \'blog\' namespace and variables like \'blog.fontname\' that the main app would populate and all blogs would use the same classes and the style and theme of each blog slice would be very similar to one another.

The presenters of this talk suggested helpers would be useful in customizing slices. For the purposes of a Standardized Slice Integration API then, we would suggest that each of the helpers have a standardized name and API across different blog slices. For example, boxes around things would be created by the \'box\' helper, and could be overridden once [once for all blog slices] to draw boxes with curvy corners, for example.

This all seems doable - just taking patience and discipline. The slightly more interesting part is that each slice implementation will be different than all others - otherwise why was it written. This magazine, for example, is a blog. Putting the content of a page of a magazine into a Wordpress blog post, or vis-a-versa, would require custom code if it is going to look decent - and a round trip, WP to magazines.me to WP again, will damage the page content.

So, not all blogs are going to be \'blog slices\' - a somewhat narrow definition will have to be arrived at for each vertical, and then perhaps special purpose translators can be written ans used to port an app\'s slice data/routes/view configuration [yes, configuration :-)] from a slice in one vertical domain to another slice in a different domain.

Another benefit of all this [yes, there\'s more :-)] is that a market for secondary tools can exist. These tools, for example, massage the data of a blog, not caring what blog it is, or who wrote it, just that it conforms to the standardizations. Blog widgets, if you will, that will work across many blog implementations.

Now, take the word blog above, and replace it with...

Carl Lerche and Yehuda Katz of EngineYard talk about mountable apps in Rails 3.