Ecosystem Dashboard

Cascading Themes for Rails view templates

This write-up is intended for the rails core team to demonstrate a use case for Ticket 8582

There is a need for some support of themes in Ruby-on-Rails. Gabe da Silveira submitted a patch that fills this need by allowing dynamically assigned "include paths" for views. This offers flexible support for end users of open source packages to customize their sites with themes. It also allows sites to support multiple themes in the context of a large network of seperate but co-dependant websites within one web application. My use case is an example of the latter situation.

The goal of "Ecosystem Dashboard" is to visualize marine ecological datasets from around the globe. It allows users to see where Marine Reserves are located, as well as see individual study sites associated with those marine reserves. Study sites will be grouped into "regions" and each region will have an associated website with graphs, community discussion, photos of marine life, etc.

marine reserves around the world

sites color coded by region

In the above example you can see that some sites belong to the "Channel Islands" set of pages. Clicking on a blue site would drive users to the Channel Islands home page. Likewise, clicking on a white site would bring users to the "Pisco" homepage. What is masked by this map however, is that the "Pisco" page also includes the Channel Islands sites in its pages, because PISCO does monitoring at all of these locations. Some sites will need to be themed by the Channel Islands theme and the Pisco themes, depending on how users reach the monitoring-site page.

Using the url to determine the region and then setting the theme to a specific region seems to be the best way of supporting this sort of functionality. I could have MonitoringSites as nested resources under Regions. The theme could then be dynamically assigned using the region name specified in the url. In cases where organizations want to use the standard theme created for the site they would have to do nothing. If they wanted to tweak the theme they could define only the changes they need for ultimate flexibility. Also, some organizations may want to contribute to our site, but then have a private front-end for their organizations website to link to. In this case they could have a public region available with the default them on our site, and a "private" or unlinked region that they link to from their website with heavy changes in the theme.

The other way of implementing this is to break up the application and have each organization host their own. The problem with that is we want users to be able to add content to a particular monitoring site. The monitoring site might lie within the "Channel Islands" page but we would also want that content available in the "PISCO" page. While it would be nice to just disallow overlap, we need flexibility to get organizations to contribute to such a content network.