Special Goals Question

special_goals_question.txt

How to solve this "special" goals question.

Since we are saving the questions through the cycle model via the
`accepts_nested_attributes`, feature in Rails, we don't need to make
more than one ajax call when saving the questions.  When we save all
the questions data, we will also use this "special" goals question (GQ)
to add the following fields to the save data.

  * cycle.goals_question_type
  * cycle.goals_question_multchoice_desc
  * cycle.goals_question_multchoice_value

--- THE GOALS QUESTION VIEW

Perhaps we make a new view that inherits from the editable-question-view.
Or maybe we can make the existing editable-question-view more configurable
and use the same code for normal questions and this special question.
More specifically, we can add more initialize options that allow us to
disable certain fields and choose which toolbar items are available.

The following items are what make the GQ view different from the regular
editable-question-views:

  * question text: set to a constant, then disabled
  * question category: set to a constant, then disabled
  * clone button: remove it
  * delete button: remove it
  * question_relationship_target_value: only provide options for self and
    direct report

--- THE GOALS QUESTION MODEL

I think we could make a new model for this goals quesiton which inherits
all its functionality from the editable-quesiton model. Maybe we add an
attribute to it to identify that its the "special" one.  Alternativly,
maybe the fact that its class name is different will be enough to distinguish
it from the regular questions.  It looks like we could make the model
behave exactly like the regular question model and we'd be good to go.

The collection would be responsible for extracting this particular one
and translating its attributes into the cycle attributes that need to
be sent to the server.


--- THE QUESTIONS COLLECTION

Now the question is, should this new GQV be part of the collection?
Each time we reset, it will get blown away by the questions array that
comes down from the server.

If it is not in the collection, we will have to manually add the view
in each time we call `renderQuestionViews()` All the questions with a
question_order of less than 0 will need to rendered and added to the
DOM first, then the "special" GQV, then all the questions that have a
question_order greater than 0.

But if it is not in the collection, we won't be listening for its `editing`
attribute to be changed to know when to re-render it in the expaneded form.

If we do put that view in the collection, we will need to manually
add it to the collection each time that the server sends down the
questions.  Then we'd need to override the collection.sort method
to account for this new special question.  And we would need to modifty
the collection.save method to add the new attributes from that question
type.

So I'm leaning towards adding the GQV to the collection and re-writing
the following methods to accomidate it:

  - collection.fetch
      add a success callback somewhere that adds the GQV and provides it
      with the attributes from the cycle (type, multchocie_desc, and
      multchocie_value)

  - collection.sort
      questions below GQV are - and above are +

  - collection.save
      find the GQV, put its model data into the proper form to send
      to the server

1. RE: Inheritance or additional customization I think that having a special view which inherits from editable-question-view is my preference. The less code paths we can have in a distinct file/class, the more maintainable our code will be. Also, creating a special goals question view would be consistent with creating a special goals question model.
2. RE: Identifying the goals question via class or via special attribute: I prefer identifying via class. Also, I agree with having the collection perform the identification and re-packaging the goals question into whatever format will be digestible by the backend. However, there is a potential downside here (and having a special goals question model, generally) which is we might not be able to put the two different types of question models in the same Backbone collection without additional tinkering. There's further discussion on the collection issue, below.
3. RE: Including the goals question in the collection or not: I think we really need to discuss this further in person as it’s very complicated, but generally speaking, the advantages of having the goals question in the collection somehow is I think it’ll make the code/issues relating to ordering simpler as we will have only one list to manage. The downside is there might be a lot of unavoidable tinkering and creation of alternative code paths for the questions collection and its corresponding view.
   On the flip side, if we keep the goals question separate from the questions collection, we will have three views to manage (questions before the goals question, the goals question and questions after the goals question) and we will need to coordinate shifting questions from before the goals question to after the goals question. I guess determining question order numbering might not be too bad, as the goals question will always be 0, and we know that the before list is limited to negative numbers and the after list is limited to positive numbers (meaning we won’t run into collision problems with assigning order numbers.