CSC/ECE 517 Fall 2014/oss E1463 vpd: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
Line 42: Line 42:
[[File:routehelpers.PNG ]]
[[File:routehelpers.PNG ]]


==only use 1 instance variable in list method==
==Minimizing the count of Instance Variables==
=== Instance Variables in Ruby ===
An instance variable has a name beginning with @, and its scope is confined to whatever object self refers to. Two different objects, even if they belong to the same class, are allowed to have different values for their instance variables. From outside the object, instance variables cannot be altered or even observed (i.e., ruby's instance variables are never public) except by whatever methods are explicitly provided by the programmer. As with globals, instance variables have the nil value until they are initialized.
 
Instance variables do not need to be declared. This indicates a flexible object structure; in fact, each instance variable is dynamically appended to an object when it is first assigned.
 
We have observed that in Expertiza, there were several code files related to the Tree Display controller which were observed to be using multiple instance variables which could be reduced. Our team aimed to limit the instantiation of such variables to only necessary places in our code.


==look at the rest of the methods==
==look at the rest of the methods==

Revision as of 12:53, 3 November 2014

E1463: Refactoring TreeDisplayController

Project Links

Our Expertiza Fork on AWS
Github Repo
Project Running on AWS
Admin Account:
Username: user2
Password: password


Project Description

For this project, our team refactored the TreeDisplayController class in the Expertiza OSS project. This class provides access to questionnaires, review rubrics, author feedback, courses, assignments, and course evaluations. The tree display lists all of these categories with the ability for the user to "drill down" into the subcategories or just expand/collapse as needed.

Example Image Of Tree Display:

Refactoring TreeDisplayController Tasks

As part of the refactoring task, we had to address the following issues for enhancing code readability and maintainability. The tasks include-

  1. Changing List to Index using a RESTful approach.
  2. Use of routing helpers
  3. Use {} and [] instead of Hash.new and Array.new
  4. Ensuring that instantiation of instance variables is minimized.


Changing List to Index

All our code changes can be checked out at our Git project repository. It can be seen that we have replaced all the controller action redirections with a tree_display_index_path which enormously reduces the code content and as well as provides an organized approach to action redirections.

combined all of the goto methods

Use Routing Helpers

We refactored the treedisplay controller class to use route helpers rather than calling ":action => 'list', :controller => 'tree_display'", or something similar. This involved many edits in the tree_display_controller.rb file and related controller and view files. Our Github repo shows all the changes made.

Example -- Route helpers added to breadcrumbs view file:

Minimizing the count of Instance Variables

Instance Variables in Ruby

An instance variable has a name beginning with @, and its scope is confined to whatever object self refers to. Two different objects, even if they belong to the same class, are allowed to have different values for their instance variables. From outside the object, instance variables cannot be altered or even observed (i.e., ruby's instance variables are never public) except by whatever methods are explicitly provided by the programmer. As with globals, instance variables have the nil value until they are initialized.

Instance variables do not need to be declared. This indicates a flexible object structure; in fact, each instance variable is dynamically appended to an object when it is first assigned.

We have observed that in Expertiza, there were several code files related to the Tree Display controller which were observed to be using multiple instance variables which could be reduced. Our team aimed to limit the instantiation of such variables to only necessary places in our code.

look at the rest of the methods

Summary and Conclusions

Future Work