Design API for AbstractModel subclasses

[cjeffers]

For @ulmerb and @jedtan:

Take a look at the tech spec for AbstractModel, and start coming up with the API for all the subclasses. They're listed under AbstractModel in the tech spec. Think about what functions we're gonna need to satisfy the functional spec.

Major considerations:

• The AbstractModel will store all the values it gets from the database in a HashMap<String, Object>, from column name to value. Should the constructor for subclasses explicitly create instance variables corresponding to each attribute? This would simplify processing-heavy code, but would require all getters and setters to change the instance variable and the underlying hash using getValue(String colname) and setValue(String colname, Object value). @jrvangogh and I talked about it and thought it would be easier to just use the getValue and setValue methods in getters and setters and never even bother with instance variables.
• What should the constructors do?
• What methods need to be overridden? Specifically should the static find* methods be overridden to return instances of the subclass?

I don't really care how you guys split this stuff up, just update the wiki with the API choices you make. Woohoo! :poop:

[ulmerb]

Did the quiz class (although waiting on setters) and working on the question class.

[cjeffers]

Some things to think about:

1. Take a look at Jacob's code and see how the superclass methods actually work, i.e. they return AbstractModel instances, not List<String>. Also calling the class method AbstractModel.getByValue() is not tied into any table (or worse is unpredictably tied to some unknown table), so you need to override the static variable instance_tablename to be the name of the table you're using, then call the static methods off your class.
2. I would suggest thinking clear through the API for the classes you're doing and putting the functions on the wiki so that at least one other person (@jedtan?) can talk over them with you to make sure you're getting all the cases. My hunch is that User will be easier than Quiz or Question, because there's less processing and more simply accessing and returning stuff from the database.

[ulmerb]

My b, I was branching off the master, not Jed's