Sinatra talk at Philly on Rails 1
Last evening, I presented a short talk about Sinatra, the Ruby microframework at Philly on Rails, the Philadelphia Ruby user group. Overall, I like it and think it has a good place on the shelf of microapp tools. As with most tiny projects that begin as someone’s itch-scratching, documentation is lacking. I hope that I can contribute in that regard as I use it more.
Here are my slides and example files.
Thanks to all who came out last night!
Routing Requirements with ResourceController 3
Since I've picked up using (and forking) ResourceController, my Controller logic has been toned down, simplistic and easy to maintain.
Presented here is just a brief example of how I tackled a solution for an artist's Art Piece Shop and Portfolio views. Keeping things RESTful, I wanted to only expose Pieces to the front-end, since they are the core of what my friend's site will be based around.
These two areas, while visually looking similar, are actually just brief changes in whats being displayed for an Art Piece.
So all I want to do is make slight changes to the template being used.
The Routes
Code examples always clear things up... ;) Here I created two routes using the requirements parameter.
map.namespace :shop do |shop|
shop.resources :pieces,
:requirements => {
:template => 'shop',
:controller => 'pieces'
}
end
map.namespace :portfolio do |portfolio|
portfolio.resources :pieces,
:requirements => {
:template => 'portfolio',
:controller => 'pieces'
}
endSo I'm creating two namespaced routes for Pieces, one for "/shop/pieces" and the other for "/portfolio/pieces".
Making :controller required overrides the default "Portfolio::PiecesController" generated controller value that is normally created with this route (I could have used :controller as a parameter, instead of part of :requirements, but its just personal preference).
I also required params[:template] to be created when this route is being handled. This is important, because we're going to need this to switch the template in our controller.
The Resource
Next, here is the ResourceController logic I used to handle this request.
class PiecesController < ResourceController::Base
actions :all, :except => [:new, :create, :edit, :update, :destroy]
index.response do |wants|
wants.html { render :template => "/pieces/#{params[:template]}" }
end
show.response do |wants|
wants.html { render :template => "/pieces/#{params[:template]}" }
end
endAs you can see here, I'm using ResourceController to only provide index and show actions. Everything is default for them, except that I would like to change how they respond_to an HTML content type.
Their response will be to just render a template for the given route, which we previously setup. Bam, done.
The Conclusion
I know there are ways to clean up some of this duplication, but it wouldn't make it as clear as it already is. The key to this is to plainly show anyone else checking out this code what I'm doing. If I had 5 routes/actions like that I might explore other options... ;)
I highly suggest checking out ResourceController, but only if you already understand how a typical Resource works. Otherwise, your not going to understand what it provides for you, and the power in that.
Request To All Tutorial Writers 1
git clone git://github.com/sam/extlib.git
git clone git://github.com/sam/do.git
cd extlib
rake install ; cd ..
cd do
cd data_objects
rake install ; cd ..
cd do_mysql # || do_postgres || do_sqlite3
rake installInstead, tell your readers to do this…
git clone git://github.com/sam/extlib.git
git clone git://github.com/sam/do.git
cd extlib
***rake spec***
rake install ; cd ..
cd do
cd data_objects
***rake spec***
rake install ; cd ..
cd do_mysql # || do_postgres || do_sqlite3
rake installMake sure that your running specs that are passing before installing edge software.
Here’s another tip, if your trying to learn new software… or wondering why something isn’t working for you… check the specs! They are a great place to learn just exactly how the author approaches using the libraries they write.
