gbpp-devel Mailing List for GradeBook ++
Status: Pre-Alpha
Brought to you by:
aviancer
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
---|
From: Williams, P. (OTS-EDH) <Pau...@bi...> - 2002-12-09 18:30:56
|
Good questions. Please read my answers inline: Paul Williams ----------------------------------------------------- There are only 10 types of people in the world ... ... those that understand binary, and those who don't. http://kevan.org/brain.cgi?Aviancer > -----Original Message----- > From: David Macgugan [mailto:dm...@ro...] > Sent: Monday, December 09, 2002 8:44 AM > To: Williams, Paul (OTS-EDH) > Subject: RE: infolastlogin fix > Importance: High > > > Hey Paul, > My SF login is dmagoo. > I guess now that I understand how the database is set > up, the next question is: where is this going? What > are our priorities. I am sure that I can answer much > of this by going through some source and reading the > "ToDo" stuff. > > It seems to me right now that things are more or less > at a "Proof of concept" stage. Yes we can log in, yes > we can add classes and students, etc. > I guess that I'm more likely to be one of the 'barbaric' types -- I just start doing something and let it evolve as needs be. I see that the majority of SF projects stall without a single checkin. That's silly. Even if we have to redesign later I'd rather get the momentum going in the form of a userbase and my creative juices (which are rather turned off at the prospect of heavily documenting The Golden Plan and One True Path.) > I think before I plug away at anything, it would be > useful to know about interface intentions. This might > affect the database structure(though I am still new to > this). For instance, when we add students to a class, > it seems that the database is "trusting us". We're the programmers. The database must always "trust" what we do. Additionally MySQL has no support for reference keys et al. I'd be willing to entertain the thought of adding integrety checks in the abstraction layer, but i just don't see it as a huge problem. If the referential integrety is bad then the whole bloody thing is gone to pot. > Meaning, > a student record is added to the DB. Also, when a > student registers him/her self, we really only have > the student id to tie them with what the teacher has > entered. I haven't tested it yet (because I am > working), but does this mean that we now have 2 > records for the same person? (One in 'User', and one > in 'Roster') In an ideal world, we would want all of > the students to be in the system already (since all > students in a school are on file), and the teacher > should be able to search and add, I suppose. I haven't really thought through student registration yet. The way some other online gradebook software handles this is to have the teacher assign a username/password to the student at the time when they're entered into the roster. A student can then log in using the single username/password, OR create an account which can aggregate all the student's classes (I suppose verifyed by the given username/password at the class level). I rather like this model, as it doesn't require a student to set up an account. It would, however, probably require an additional db table when we get there. > This leads me to believe that 'User' should be a much > simpler table. Not all people will necesarily be > users. Perhaps there should be a separate table with > name, etc, and all the contact info of a person. The > user table can simply have a pointer to the right > entry in the new table. Does this make sense at all? > I am thinking out loud. I think that my above comment kinda reflects what you were saying. Basically the "people" table you talk about is embeded in the roster, and if a student creates an user account s/he has the option of adding pointers if you will to all the various roster rows. Same idea. This leaves the problem of correlating students in different classes to the student rather than the instructor/administrator. > BTW, should I be spitting > this out to the mailing list instead? Yes, this should be captured for prosterity. I've just created a gbpp-devel mailing list which will be active sometime in the next 24 hours. I'll forward a copy of this message there. > In short, I suppose we should prioritize. I am sure > you have plans, but am not sure what they are. > Priority (1) : get it working to the point a teacher can enter data and get a grade report. That will be version 0.1b. Priority (2) : Students can check their progress via simple login as assigned by the teacher. This will require multiple logins to check multiple classes. This is version 0.2b. Priority (3) : Students can create an account and collect their classes under one login. Version 0.3b Priority (4) : Parent logins tied (somehow) to the student login. Version 1.0 ... TBD after that. Thanks!!!!! ~ Paul > Take care, > -Dave > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > Notice: This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system. Thank you. |