CSC/ECE 517 Spring 2014/oss E1401 lmn

Introduction

Background

Assignments in Expertiza have many components--due dates and topics, for example. Due dates and topics are objects in their own right (DueDate, SignupTopic); we need a way to have sets of due dates and topics associated with an assignment. There are also separate forms to create and edit an Assignment and its components (Topics, Due Dates), these forms should be unified into one form for every component of an Assignment. Also, it'd be nice if we could sort assignment due dates in order of next due.

What Needs to be Done

• Remove the separate New and Edit forms for assignment
• Create a form object to encapsulate the creation and editing of Assignments, Due Dates, and Topics
• Add the ability to sort Due Dates

Classes

Changed existent classes

• controllers/assignments_controller.rb
• models/due_date.rb
• views/assignments/new.html.erb
• views/assignments/edit.html.erb
• views/assignments/edit/_add_signup_topics.html.erb
• views/assignments/edit/_due_dates.html.erb
• views/assignments/edit/_general.html.erb
• views/assignments/edit/_rubrics.html.erb

Added classes

• models/AssignmentFormObject.rb
• controllers/assignment_form_object_controller.rb
• helpers/assignment_form_object_helper.rb
• views/assignment_form_object/new.erb
• views/assignments/new/_add_signup_topics.html.erb
• views/assignments/new/_due_dates.html.erb
• views/assignments/new/_general.html.erb
• views/assignments/new/_late_policy.html.erb
• views/assignments/new/_review_strategy.html.erb
• views/assignments/new/_rubrics.html.erb

Objectives

• All CUD (Create, Update, Delete) operations on Assignments, Due Dates, and Topics should be performed through an AssignmentFormObject
• Assignment, Due Date, and Topic views and controllers should be subsumed into a combined AssignmentFormObject view and controller

Design and Implementation

As a bit of background, form objects[1] could be thought of as a fake model that is not itself persisted but persists all its component models. A form object acts like a model in that it can have validations, have persistence strategies, and return whether or not it is persisted. Behind the scenes it is intelligently manipulating other models to provide this functionality transparently, encapsulating the required logic.

Our design uses one form object, AssignmentFormObject, to store data about the base Assignment model and Due Date and Topic models associated to that Assignment. In this way we can achieve both objectives, utilizing the form object to create, update, and delete Assignments and associated Due Date and Topics without having to have separate controllers and views for each.

Without knowing anything about form objects, it is easy to tell what is going on when you attempt to persist an AssignmentFormObject:

Assignment.transaction do
      if @assignment.save

        topics_list.each do |a|
          a.assignment = @assignment
          if !a.save
            raise ActiveRecord::Rollback
          end
        end

        due_dates_list.each do |a|
          a.assignment = @assignment
          if !a.save
            raise ActiveRecord::Rollback
          end
        end

The form object starts a transaction (in order to guarantee that either everything or nothing is saved) then attempts to create (or update) the Assignment. If this succeeds, it moves on to the components of the Assignment, doing the same. These inputs are passed to the form object previously, using Virtus[2] to create validations on the attributes passed.

Because the form object can be treated like a model, writing a controller to populate views with it is just as easy as with a normal model, as shown.

  def create
    @assignment_form_object = AssignmentFormObject.new(params)
    if @assignment_form_object.save
      alert("Form saved")
    else
      alert("Error saving form")
    end
  end