Browsing articles tagged with " Rails 3.2"

Rails 3.2: A Nested-Form Demo Part 4: Switch to Targeting Computer!

Feb 26, 2013 // by Jeff Johnson // Blog // No Comments

Overview

Our heroes have fought their way through the Death Star’s fighter screen and can see the trench. As they enter the trench our pilots stabilize their deflector shields, preparing for the torrent of incoming turbolaser fire that will no doubt be coming their way.

In this post, we’ll take a look at adding some validation rules to our Ship and Pilot models. Hopefully, this effort will prevent our users from… err… having their way with our meek and rather naive Starfighter Recognition Guide. Our exhaust port is small, it’d be a shame to see it damaged by some ham-fisted users.

Validation

In our last post we walked away with a fully-functioning Starfighter Recognition Guide that could save a Ship and any changes (create/update/delete) to its associated Pilots. Neat, right?

Before we run off and save everything willy-nilly, we should probably go about checking to make sure our users provided the data we need. Let’s add some data entry requirements to our application, shall we? Here’s what we need to do:

Ship Requirements

A Ship must have a name.
A Ship‘s name must be between 3 and 50 characters.
A Ship must have a crew.
A Shipmust have between 1 and 5 crew members.
- Arbitrary? Sure. But I figure if a Ship has more than 5 crew members, it’s probably a capital ship or on a scale that isn’t appropriate for a Starfighter Recognition Guide.
A Ship must have a speed.
A Ship‘s speed must be between 50 and 200… err… thingies per… umm… unit of time.
- At the risk of having my Star Wars nerd card revoked, I’m not sure how the speed of a starfighter is measured. Yes, I looked it up. Nope, I couldn’t find anything conclusive.

Rails 3.2: A Nested-Form Demo, Part 3: We’re Starting Our Attack Run!

Feb 8, 2013 // by Jeff Johnson // Blog // No Comments

Overview

When we last left our heroes, they fought their way through the superstructure of our application and were setting up to finish it off. Having defeated the TIE fighter screen, our intrepid fighter pilots have descended into the trench of the Starfighter Recognition Guide. Their computers are locked, they’re getting a signal…

In this post, we’ll capitalize on the code and plumbing we implemented here and here. We’ll take a look at the views we put in place and some javascript to make our Starfighter Recognition Guide a bit fancy-pants.

Stabilize your rear deflectors and watch for enemy fighters – there’s gonna be a tubolaser battery’s worth of code in this one.

Rails 3.2: A Nested-Form Demo, Part 2: Accelerate to Attack Speed!

Jan 24, 2013 // by Jeff Johnson // Blog // No Comments

Overview

In our previous post, our intrepid heroes were hurtling headlong into the trenches of the Starfighter Recognition Guide. They maneuvered through the superstructure of the application, setting up a relationship between themselves (the Pilots) and the Ships they fly. In this post, our ace Rebel pilots will make their approach to the surface of our application.

The Controller

Because all of the heavy lifting is being handled by the ActiveRecord configuration defined in our domain model, the controller for the Ship model is pretty standard fare. As a quick refresher, here’s what the create method in the ships_controller looks like:

  def create
    @ship = Ship.new(params[:ship])

    if @ship.save
      redirect_to(ships_path, :notice => "The #{ @ship.name } ship has been saved successfully.")
    else
      render(:new, :error => @ship.errors)
    end
  end

If you’re interested in looking at the controller in its entirety, you can check it out here.

Rails 3.2: A Nested-Form Demo, Part 1: All Wings Report In!

Jan 19, 2013 // by Jeff Johnson // Blog // No Comments

Background

I’ve been working on a Rails 3.2 project for the last several months. While it’s been a blast to learn a new technology stack (I’ve spent most of my career working with .NET), there have definitely been some bumps in the road. In particular, I’ve spent the last couple weeks working on persisting a model that has a parent-child relationship. The bulk of that time was spent poking around the inter-webs, looking for tips and tricks to accomplish my goal. During my inter-web search, I couldn’t find a single post (or series of posts) that had a complete example or tutorial on how to persist a model that has a parent/child relationship. My Google-fu might not be as good as some other developers out there, but I searched pretty hard. What I found were bits and pieces scattered about (primarily on my savior, Stackoverflow). After a LOT of trial and error (mostly the latter), I finally have it working. So I thought I’d collect my notes as a series of posts. FYI - this started as one post, but got WAY too long. Even for me.

Objective/Goals

Reading is real neat, and I do a whole lot of it. I tend to learn by doing, so reading only gets me halfway there. To that end, we’ll build a demo application that ultimately addresses the following:

Allows a user to save a model that has a parent/child relationship.
- The operation will allow us to save the parent object as well as insert/update/delete new child objects that are associated to the parent.

Rails 3.2: A Nested-Form Demo Part 4: Switch to Targeting Computer!

Overview

Validation

Ship Requirements

Rails 3.2: A Nested-Form Demo, Part 3: We’re Starting Our Attack Run!

Overview

Rails 3.2: A Nested-Form Demo, Part 2: Accelerate to Attack Speed!

Overview

The Controller

Rails 3.2: A Nested-Form Demo, Part 1: All Wings Report In!

Background

Objective/Goals

Recent Posts

Tag Cloud