# Wednesday, 26 September 2007

jaoo2007_1 ActionPack is the frontend part of the Ruby on Rails framework and was derived from a commercial project 37signals did called Backpack. The guys at 37signals had an idea for a commercial project and didn't want to build it on top of the stacks common three years ago. Features are added to Rails as they are needed in commercial projects. A lot of plumbing was required before Rails at the time of its inception. With Rails 50 lines of code is reduced to 3. The change in thinking comes from going from explicit definition of your intent to implicit definition or convention over configuration as is the mantra of Rails.

Routing decides how we get from a URL to a piece of code. Routes are defined in a file called routes.rb which can be edited as you see fit. You don't have to configure routes you can go by convention alone, if you have an action (a method) on a class you can specify the path in the URL and the routing system will figure out which piece of code to execute. URLs are treated as sitename.com/:controller/:action/:id (the : denotes a variable) default and that's make makes the magic happen. Routing is basically URL rewriting. Everything is configured using Ruby, XML is apparently not something they like on the Ruby side, I kind of get where they're coming from too :)

View Context is a lot of different thing, but basically we're talking about how data from the request is accessed in the various parts of the framework. You have view contexts for template params (page scope), variables* (request), flash (something needed for a short time between redirects), cookies, no application scope.

Everything is bound together by name by default but you can override the default behavior by using the redirect_to or render keywords. Redirect sends a 302 to the browser and sends the user to a different form. Render renders a form in the same folder. render :partial is basically server side includes whereby you include one piece of UI into another.

Of course ActivePack has Filters like we were introduced to earlier in the MonoRail talk. Filters are methods that you want to be called prior to or after the action. You can use filters for authentication, authorization, logging, etc.. You defined them on the controller itself by specifying a before_filter :action. You can layer these guys to do different stuff if you need to. verify is a before filter you use to specify that a method can only be accessed through a post for example.

Rendering render :action, render :partial render :template. ERB methods is code you can use inside your templates. @ denotes an instance level property. Instance variables are automatically available to you in the view (HTML). You basically place the code inside <%%> tags like we're familiar with in good old ASP. h() HTML escapes text and u() URL encodes the string.

Formatting helpers are encapsulation of general purpose tags you can use in your HTML. You can use these for formatting dates, numbers, currency, build forms, etc.. Examples of helpers are form_tag which starts a HTML form, text_field which outputs an input, submit_tag which outputs a submit button for the form. They will create both a name and an id for JavaScript compatibility.

Layouts are the Ruby on Rails version of master pages which enabled you to get a unified look and feel for you web application.

Comments are closed.