The Artima Developer Community
Sponsored Link

Agile Buzz Forum
Ruby on Rails

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
James Robertson

Posts: 29924
Nickname: jarober61
Registered: Jun, 2003

David Buck, Smalltalker at large
Ruby on Rails Posted: Apr 30, 2007 10:43 AM
Reply to this message Reply

This post originated from an RSS feed registered with Agile Buzz by James Robertson.
Original Post: Ruby on Rails
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
Latest Agile Buzz Posts
Latest Agile Buzz Posts by James Robertson
Latest Posts From Cincom Smalltalk Blog - Smalltalk with Rants

Advertisement

So part 2 - Ruby on Rails. First - use the packager and install Rails. "What is Rails?" Rails is a wrapper around a bunch of other little frameworks. The core is made up of ActiveRecord and ActionPack. ActiveRecord is a simple O/R mapping pattern. ActionPack implements the web-facing piece, implementing an MVC pattern for the web. The big thing to remember about Rails is this:

Convention over Configuration

One of the results of this is that using Ruby, you don't end up arguing over things like "which db framework, which directory structure...", etc. etc. So the first step - create an ActiveRecord subclass for the first bit of the domain, and then use some Ruby code to create a table for it. The class Chad created has more fields, but you get the idea:

 

class CeateContacts < ActiveRecord::Migration
	def self.up
	       create_table :contacts do | t |
	       t.column :first_name, :string
	       t.column :last_name, :string
		 t.column :created_at, :datetime
	end
end

def self.down
	drop.table :contacts
end

end

Class Contact < ActiveRecord::Base
end


That last bit does the class to table mapping. That's it - by following this convention, we have the mapping. Note that we didn't worry about primary keys, SQL (etc, etc). You can name various columns in ways that will automatically map to the database in intelligent ways.

There's a nice log being kept for you that saves a record of your database interactions; this can be useful for figuring out what SQL is being created, and where you may need to tweak.

Some more code - a controller (the handler for actions on the back end). There would typically be a view here for rendering, but we are just being simple (like my web examples in my screencasts :) )


class ContactsController < ApplicationController
def index
	@contacts = Contact.find(:all)
	render :text => @contacts.inspect
end

Now a new View HTML Page (in its own directory structure spot) to handle the rendering. Like web toolkit (and other web frameworks), there's a way to embed Ruby code in pages


<html>
<body>
	<h1>Contacts!</h1>
	<ul>
	<% @contacts.each do | contact | %>
		<li><%= contact.first_name %><%= contact.last_name %></li>
	<% end %>
	</ul>
</body>
</html>

Simply change the controller to eliminate the specific rendering using inspect. The framework also handles giving you basic forms for editing domain objects based on the Ruby and DB definitions. There are a number of built in things for pagination, number of items per page (etc, etc).

With respect to code generation, Chad finds it to be mostly useful for "getting started" and setting up the initial scaffolding.

Technorati Tags:

Read: Ruby on Rails

Topic: Test Driven Development best resources Previous Topic   Next Topic Topic: Smalltalk Daily 4/27/07: Automating an image build, redux

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use