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

• controllers/assignments_controller.rb
• controllers/due_date_controller.rb
• controllers/sign_up_sheet_controller.rb
• models/due_date.rb
• models/sign_up_topic.rb

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<ref>http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/</ref> could be thought of as a fake model that is not itself persisted but persists all its component models. The name comes from the idea that many times forms do not require information for just one model but several at a time. Creating a series of forms to work with each model at a time is tedious and frustrating. A form object fixes this problem by acting like a model. It can have validations, have persistence strategies, and return whether or not it is persisted, just like a model. 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<ref>https://github.com/solnic/virtus</ref> 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

Affected 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

Future Work

As with every project there are always more things to be done. With the use of a form object there are side benefits that we can take advantage of with more effort that we just didn't have time for. There are also some problematic areas we uncovered during the project that could use cleaning up. The following additional steps (or features) should be taken (or implemented) by anyone continuing with the project.

• Ability to add multiple sign up topics from a new form
• Ability to add rubric details from a new form
• Redo the due dates partial to be more readable and use rails conventions rather than JavaScript
• Redo the due dates partial in general, it is very messy and difficult to work with
• Relocate JavaScript scripts to another.js resource file rather than in-line in the html
• Eliminate the need to have multiple calls to the same controller methods for every table entry for due dates on the edit pages

References

<references/>