1

Ruby on Rails shell commands

Posted by jason on Jan 6, 2010 in Ruby

This is just a reminder to me about commands that I use.

rails appname
rake --tasks
rake db:create
rake db:drop
rake db:migrate
script/generate controller myobject
script/generate model Person name:string age:integer
script/generate scaffold Person name:string age:integer

 
0

Ruby on Rails ORM through ActiveRecord

Posted by jason on Jan 6, 2010 in Ruby

Rails offers an ORM layer.  This layer is not a very strict layer.  To filter or sort objects, you are actually writing SQL code.  There doesn’t seem to be much complaining in the community about this mis-feature.  In fact in the Agile Web Development with Rails book, the author basically makes snide comments about people who think that the object hierarchy and the database model should not be tied tightly together.  This may just be a cultural thing.  Ruby on Rails seems to be used mostly on brand new projects.  Given this situation, it is understandable why Rails developers don’t understand the importance of uncoupling the database from the object graph.

One of my first consulting jobs was with AMC Theaters.  I was on a tiny project that needed to read from a database that we had absolutely no control over.  Unfortunately for us, the tables and fields often had entirely different purposes than what they were labeled as.  These corporate databases can last decades and changing them is not possible.  Many different groups have written code around these names and changing a field in a table has ramifications way beyond our little group.  It would cause applications to break and there is no funding to fix all the applications just because we don’t like the field name.  Consequently, you are left with the task of mapping a field in a table that has a non-sense name to a field in the object that actually makes sense when you read the code.  This is where Ruby fails to deliver with it’s implementation of ORM through ActiveRecord.

Since I’m learning Rails so I can create new ideas quickly, I will happily use the current ORM.  But this is one area where Rails needs to improve.

 
0

Ruby on Rails Layouts

Posted by jason on Jan 6, 2010 in Ruby

Site wide layout

One common method of creating common look and feels in web development is to split up all the common code into a header file and a footer file and include those files in every single interface page.  This is better than embedding all that html code inside each page, but it is still clunky.  You can not easily see where your tags open and close because they can be opened in one file and closed in another file.  More advanced mechanisms put the overall code in one file but have middle sections where code specific html goes.  So, your html template file would look something like:

<html>
  <body>
    <%= yield %>
  </body>
</html>

It is easy to see the structure of an html page this way.  It also cleans up the code for your view.  Ruby on Rails implements this style of templating and calls it layouts.  Because of Rails’ convention over configuration, to implement a site wide template, you merely need to create /app/views/layouts/application.html.erb and put your site wide html code there.

Override default layout

You can override the layout that will be used by adding a layout declaration inside your controller class like this:

class HelloController < ApplicationController

  layout "mylayout"

  def index
  end
end

Create /app/views/layouts/mylayout.html.erb

Two different layouts, same view

You may have different layouts depending on whether the user is logged in or not.  This is easy to accomplish by using a symbol for the layout.

class HelloController < ApplicationController

  layout :isLoggedInLayout

  def index
  end

private
  def isLoggedInLayout
    "loggedIn"
  else
    "notLoggedIn"
  end
end

You would have two templates, one /app/views/layouts/loggedIn.html.erb, the other /app/views/layouts/notLoggedIn.html.erb.

Copyright © 2010 programming with passion All rights reserved. Theme by Laptop Geek.