ddsnowboard
commented
8 years ago OK, so getting the new features necessary for this to work into the StockChoiceField is proving quite challenging.
The first issue was getting two of them to work on a page separately. I have been trying all sorts of ugly stuff, but I think what I can do is just set up the script so that it renders as many as it finds separately. This way, I can just query the DOM for all of them, shove that query (it's kinda sorta like a list, under the hood) into a for loop, and they will all work, I think.
The problem will be getting them to load the right stocks, which is another new feature. I have pondered making it so that they send something about their names into the URL that they use to asynchronously download their data, but that would require me to write to the database when I'm rendering the form and then call that database again from a new view, which could be slow, but more importantly probably wouldn't work if more than one person is using the site at once, since there is no difference on the client side between any two rendered forms with regard to id's or classes.
What if I look at the URL with JavaScript? Although this wouldn't be very portable to other parts of the code, it would work because I've set up the URL's such that they either have the primary key of a user, which is really easy to look up in the database in a view, or a floor and a stock, which is kinda easy. The problem is, as I said before, that would be practically unusable anywhere else because the URL wouldn't be set up like that. Also, that would work for the one that shows the other player's stocks, but the one that is showing the user's stocks wouldn't know what it was and show the wrong thing.
I could give the JavaScript for the widget a hook that lets something else change its data and make a global list of the individual widgets, and then I could shoot in another script as media for the actual Trade Form and tell it to pick up the list of widgets, look at their id's, the URL, and what is above them (ie, usernames) and figure out what is going on, then whip up some new URL's for them to get data from based on all that. That might be ugly, but it would be portable, and probably more effective than my other options, most of which involve rain dances and human sacrifice.
See the spec for more details, but it should really be a skeletal template backed by a form with some styles on it. The main issue will be notifying the other user that there is a message for them. This will probably require a new field, and so some migrations and some other things. It could be interesting.
StockChoiceField)StockChoiceFieldwork withUserChoiceFieldThe last one could be challenging. I guess I could have a
Trademodel withForeignKeys for sender and receiver, and two fields with a bunch of stocks in them. It would have to have loads of checking functionality in it, though, to make sure that you don't trade a stock that you don't own anymore. That could get a little hairy, but I think I can make it work. I guess I would also have to either have something in there that checks if it has the floor itself as a participant, in which case it would automatically accept. This might not be so hard. We'll see.