Locks scare me. What if something gets locked and someone walks off?
Then its forever uneditable, or else we put in time limits and that gets
ugly real quick. I like Steven's idea better, but then management
becomes a headache. This is something we should all think about for a
little more time, perhaps, and continue to discuss.
Anyway, another thing -- I think it would be best to move from the (cool
looking) AJAX implementation for six_teams.php to a more traditional
page-load system to fill in all the data. Unless someone has some mad
XML-parsing-in-JavaScript skills, I can imagine 100 different requests
going in each time someone loads one page, opening 100 queries to the
db, etc... Much better in my opinion to manage it all on page load.
Thoughts?
~Ryan
Steven Buss wrote:
I think you've got some good ideas.
I think we should keep multiple entries for scouting information, that way if someone does something malicious, its possible to revert back to old (and good) data. Instead of updates to existing data, all new data would be appended to the database. Each entry is linked to the user, and given a timestamp. The most recent data should be displayed unless its flagged by an admin, in which case the previous entry is displayed until action is taken on the offending data.
This brings me to a question, how are we going to assign scouting duties? I will only be at one of the local competitions, is there a mechanism to assign matches? Are we going to roll this out at just a few regionals this year, or try to get to every one? If its just a few it would be easier for us to coordinate eveyrthing and get the bugs worked out. Comments?
On 2/8/06, *Brandon Ripley* < Brandon.Ripley@xxxxxxxxxx <mailto:Brandon.Ripley@xxxxxxxxxx> > wrote:
My suggestions:
Whenever the scouting input page is loaded, it should query the database and fill out all the values on the webpage with the data stored in the database for that match and robot. Clicking submit would then overwrite the old data with the new data.
To make multi-user simultaneous entry work, we need to have a way to identify what robots each scout is scouting. Adding a scoutLock and lockTime field to the matchRobotData table could accomplish this. The scoutLock field would indicate what username is scouting this robot and the time the scout took out that lock. In order to set the lock, we need to add functionality to allow scouts to indicate what robots he or she will be scouting. This could be done by adding a checkbox above each of the six robot scout boxes on the scouting input page. When the page initially loads, the six scouting input areas will be grayed out and the scout can only check the select boxes to indicate what robots he or she will be scouting. Once the scout hits the "Submit My Robot List" button, the page will reload and the scout can enter values for those robots. If another scout submits the same robot(s) to be scouted, his or her page will reload and only the robots not already accounted for will be available for data entry. Additionally, the scouting input page should display the username of who is scouting what robots. This will help solve the problem of forgetting to scout a robot, because an unscouted robot will not have a scout username assigned to it. Now, if for some reason, a scout selects to scout a robot and doesn't, someone needs to be able to get in there and enter the data after the match. This can be accomplished by only allowing the lock to be valid for a short time, such as two minutes. (Each time someone tries to submit scouting data, the username should first be compared to the scoutLock name, if they match, the submit succeeds. If the usernames are not the same, check the lockTime. If the current time is later than the lockTime plus the scout lock timeout constant, allow the submit, otherwise, return an error message stating you are not scouting this robot.)
To further safeguard the overwriting of scouting data, we could add a uniqueID field to the matchRobotData table. Each time someone updates that row, this field would be written with a new random ID. This ID would be written to a hidden field for each robot in the scouting input page. Upon submit, the ID stored in the form and the ID in the database would be compared. If they don't match, someone else updated that robot's data between the time you loaded the page and the time you changed the data and hit submit. The scouting input page would display an error message stating the discrepancy and it would display the robot's score from the database in the scouting page. The user could then do nothing to keep the score that someone else entered or else re-enter his/her data for that robot and overwrite what is in the database.
Got it?!
Brandon
-----Original Message----- From: Ryan McElroy [mailto:ryan@xxxxxxxxxxxxxxxxx <mailto:ryan@xxxxxxxxxxxxxxxxx>] Sent: Tuesday, February 07, 2006 11:27 PM To: stamp@xxxxxxxxxxxxx <mailto:stamp@xxxxxxxxxxxxx> Subject: [stamp] Database entry
I think there is something about the overall design of this app that I am not understanding. When the match input page comes up, is it supposed to be filled with the last version of the match info submitted? If we want that to happen dynamically, someone with more (ie, any) AJAX experience should probably do it.
Also, what do we want to happen when we submit? Overwrite whatever is there with the stuff just submitted, or try to intelligently figure out what should be updated (ie, things with zeros should not be updated?)... I guess the crucial question is is there single-computer input or multi-computer input for a single match? If the latter, how are we dealing with inconsistencies?
Stephen, I haven't taken a look at your database classes, and I don't have any experience using things of the sort (I'm more of a PHP hacker than a PHP programmer). So, I'd like your opinion on how helpful you think they will be in this case, and perhaps the best way to use them (maybe a mini-tutorial?)
Thanks,
~Ryan
--
Steven Buss
steven.buss@xxxxxxxxx <mailto:steven.buss@xxxxxxxxx>
PHP/MySQL programmer
