Add some more fields to the Floor model to better reflect the spec, and write a bunch of unit tests.
Add a maximum number of stocks field to the Floor model, as in the spec. A lot of the commits (before the testing ones) are about getting all the other stuff to look at that field and act intelligently with regard to it. I also had to change some things about how it works, and I changed the spec to match those. Furthermore, I added some fancy JavaScript to the Trade page to tell you when you are breaking your floor's maximum, so that's nice.
Improved the Create Floor page to reflect these new changes. Now, it has more fields on it, as well as having a script attached to it that complains to you if you don't give your floor enough stocks, as specified in the spec.
As a result of extra complexities in the Trade page, I did some refactoring of the JavaScript for that page, including making a new file called tradeCommon.js. This covers all the things on the trade page that are the same between the actual Trade page and the Received Trade page.
Refactored a bunch of stuff to use Hungarian Notation (eg. pkFloor if it is a floor's primary key, instead of floor if it is an actual Floor object.) I have been needing to do this forever, and I realized it in the middle of writing a bunch of other stuff, so half of it was already done. This makes it way easier to figure out what you're looking at, which is really nice, because before this you just had to know what was going on, or make mistakes. NB that if something doesn't have pk before its name, it is an object.
I added some help texts to some of the fields on the CreateFloor form, to elucidate some of the more complex options that the user has for floors.
I added to_json methods for some key models, just so they're around. I would use a __dict__ magic method so I can just use the json class like a normal person, but you can't do that with Django because it uses metaclasses.
There was a serious error in Player.receivedRequests() that I fixed. That was a close one.
Did some work with error handling. This was the most problematic. I changed some things so that they would make more sense (ie, I decided that TradeErrors should be the user's fault and get shown to him in angry red text, but when I make a mistake, I get a RuntimeError.) I tried to get it to work better, and I think I did, to some degree, but it's far from bulletproof. I should do some more work on this. Also, the formatting of error messages is terrible. I need to do some CSS to make that a little nicer.
Added an trigger to the stockWidget that runs whenever anything changes because I needed one, although it could come in handy later.
Update to Django 1.9 because there was a testing function that I needed that was only in the newest version.
Add some more fields to the
Floormodel to better reflect the spec, and write a bunch of unit tests.Floormodel, as in the spec. A lot of the commits (before the testing ones) are about getting all the other stuff to look at that field and act intelligently with regard to it. I also had to change some things about how it works, and I changed the spec to match those. Furthermore, I added some fancy JavaScript to the Trade page to tell you when you are breaking your floor's maximum, so that's nice.tradeCommon.js. This covers all the things on the trade page that are the same between the actual Trade page and the Received Trade page.pkFloorif it is a floor's primary key, instead offloorif it is an actualFloorobject.) I have been needing to do this forever, and I realized it in the middle of writing a bunch of other stuff, so half of it was already done. This makes it way easier to figure out what you're looking at, which is really nice, because before this you just had to know what was going on, or make mistakes. NB that if something doesn't havepkbefore its name, it is an object.CreateFloorform, to elucidate some of the more complex options that the user has for floors.to_jsonmethods for some key models, just so they're around. I would use a__dict__magic method so I can just use thejsonclass like a normal person, but you can't do that with Django because it uses metaclasses.Player.receivedRequests()that I fixed. That was a close one.TradeErrors should be the user's fault and get shown to him in angry red text, but when I make a mistake, I get aRuntimeError.) I tried to get it to work better, and I think I did, to some degree, but it's far from bulletproof. I should do some more work on this. Also, the formatting of error messages is terrible. I need to do some CSS to make that a little nicer.stockWidgetthat runs whenever anything changes because I needed one, although it could come in handy later.Close #17.