Day 33 – Controllers and Views

Today marked the end of playtime in the console with the database and Active Record. Seeing as I’d gotten Rails models and ORM queries pretty much down, it was time to integrate with controllers and views. Rails is really nice in that you can generate so many pieces of the project with single line commands in the terminal. For models, the rails g model NAME [fields] command will automatically create the model class file and the migration file for updating the database. When you generate a controller you get even more! rails g controller NAME_PLURAL [methods] will not only create a controller class file with the specified methods, but it will also generate the beginnings of routes as well as view files for every specified method. Plus, with the render by default feature in Rails, all you need to do is fix up your routes a bit and the server will be ready to start serving the automatically generated views corresponding to your controller methods.

The basics of passing data to the views with the controller are very similar to how it was done back in Django, but with Rails you don’t even need to inject a context dictionary. Any instance variable (instance variables look like @variable_name) declared in the controller method is available to the view automatically! So, if you want to grab all the users from your database, you can just pop in a simple @users = User.all and you’re good to go. I still haven’t used it much yet, but the templating language in Rails’ .html.erb view files seems pretty nice. It works similarly to Django’s so far, but instead of {% %} for blocks and {{ }} for text, Rails uses <% %> and <%= %>, respectively.

Other differences I’ve noticed so far have to do with how Ruby uses a params hash (dictionary) to pass both route parameters and post data to controller methods. Back in Django, route parameters were captured with regular expressions and assigned to variables to be passed to methods directly and post data was passed through request.POST. I never tried testing this, but I’m pretty sure the request.POST is only available if the request.method really is "POST". However, in Ruby on Rails it seems like there’s always a params hash no matter what the request method is, and all parameters – including route parameters, post data, and other request data – are stored there for use in the controller method. I suppose that’s pretty handy, but I can’t help but think that I kinda liked the separation of route parameters and post data back in Django.

By the end of the day, I started getting into SCAFFOLDING. Haven’t gotten too deep into it yet, but holy shit, it’s basically like building a fully functional site (all CRUD operations on some model) with just a couple lines of code! Now I’m really starting to understand why Ruby on Rails is great for prototyping!

(note: featured image grabbed from http://perfectial.com/blog/is-ruby-on-rails-dead/)
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s