Routing

Dashboard was originally a single-page Sinatra app, and it shows in the routing. I’ve recently gone through and tried to clean things up, but I cut my teeth on Rails before RESTful routing was all the rage. At this point, we have three “resourceful” models: Groups, Projects, and Personal Blogs. Things are routed such that you can get to projects and personal blogs directly, but they really should be attached to groups. At this point, groups have many projects and personal_blogs, but the mapping is a simple one-to-many. In the future, we will need to support a many-to-many association here, which is why the routes support direct access to projects and personal blogs.

Interesting routes

These are the really interesting pages to hit. Everything else is really just built around them as support. Standard RESTful routes apply for handling CRUD operations on the models. Authentication is sort of half-baked using project-level and group-level passwords.

/

In the master branch, this maps to the index page for all groups, which should theoretically be a nice overview of all of the groups hosted on this installation. Currently, though, the action in the GroupsController redirects you to the dashboard page for the newest group (Group.last).

/groups/dashboard/:id (:id is group id)

This is the core of OSS Dashboard. The dashboard page is inherited from the original one-off Sinatra app, and hasn’t changed all that much from it. The only real menu system in the app sits at the top of this page.

/groups/feed/:id

A nice aggregate of all of the project blogs and personal blogs attached to the specified group. This is also provided in Atom format at /groups/feed/:id.atom and referenced with a tag in the header of the HTML output. To make page caching work with pagination, the page parameter is forced into the url, giving you something like /groups/feed/1/page/2, which is easily cached.