New Mouse Pages Done
Note to self: ctrl-x-s is the shortcut for saving when emacs menus don't work
I eased myself back into really working on this today--if I'm not careful I get scared to start. But it's going really really well. I wrote queries for entering a new mouse, and then I wrote the php and set up the page that displays the results so you can see what you entered. What was really cool was there were very few errors (like missing quote marks) that I had to fix. It was a lot easier than some of the first pages were.
Unfortunately user errors during entering aren't as easy to fix as entering a reading twice or something--you can't just delete everything and re-enter it. So I included instructions in case of errors: contact your local database guru. lol. I'm not sure how to take care of these kind of errors as a more permanent solution. In order to set everything right a person really needs to know how the database is set up and the actual queries that the php sends. It's kind of a bummer, but any non-CS people who use this will probably need to keep a CS person on hand. At least I can wire in enough that the CS person doesn't have to be called on for a every single thing, but... well, I guess being needed is handy ;-)
I only have Cage Transfer and Record Death pages left. I'm not going to tackle the view full record until I get back to Westmont. It should be pretty easy--the new mouse page already includes the query I'll need for both transfers and deaths, so there can be a fair amount of copy and paste. (I wish I could do it tonight and get it all done, but I've already been working on this for like 9 hours today, and it's almost midnight). After that is done though, comes the most difficult part: figuring out how to add everything to the database so that Dr. McMahon can start using them. I'm working on it, but I think I need to brainstorm with Dr. Iba a bit.
1 Comments:
Regarding handling entry errors, we might employ a transaction that gives the user a summary view of the changes resulting from the data entered and then requires a confirmation to actually "commit" the changes to the database. If the user cancels we simply "rollback" the in-progress changes and let them start over. (Something to think about anyway -- we can discuss it later.)
But once again, do not get side-tracked from the Paranoid Swarming doing this. It would be one thing if you need a diversion, but don't let it become a distraction.
--wfi
Post a Comment
<< Home