[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[seul-edu] gradbook project for june 2002 delivery
hello,
these two files (.txt and .jpg) outline a proposed approach.
mike eschman, etc...
"Not just an afterthought...
arch.jpg
EXISTING PROJECTS KNOWN TO THE LIST : FINDING A BASIS TO CODE ON TOP OF
synopsis : Starting with Storm ( http://utstorm.sourceforge.net/ ) from the University
of Toronto as a base, without becoming tied to Storm (I.E. let the source mutate to fill
our requirements list) , looks like it would make a lot of sense. The Storm product has
been in "production" for well over a decade, uses mysql with mod-Perl, is GNU and is utility
friendly (coming with 25 working utility functions).
Because we know Basmati is known to the list and has active users who contribute to the list,
it makes sense to think about writing a 26th Storm utility to enable import/export between
Storm and Basmadi.
Internationalization has been raised as a fundamental issue. Implementing Unicode in Storm
would provide a solid basis for this. (Writing in your native tongue is a prerequisite for
international code).
Fabricating a GUI front end, writing a grade weighting utility, and adding a demographics
utility suite appear to be necessary :
(1) Writing the GUI gives some capacity to ease user interface issues.
(2) The grade weighting utility(s) provide a mechanism to calculate the grade.
(3) The demographics module provides a place for student profiles (address history,
incident tracking, medical records and what have you).
New utilities might be as simple as importing an excel spreadsheet or dumping an
administrative file in blank or comma delimited format, for import into mysql.
The GUI would be configured by the user. I am hoping this is as simple as tying
a button to a script with a specific input and output.
So the GUI would be a series of two types of buttons. One set of buttons
maps blank input fields to database fields, by depressing the button. Then,
click on "submit" and the database is updated. The other set of buttons causes
a script to execute (calculate grade "weighting" for example).
This style of GUI is able to "absorb" lots of pre-existing work, allowing for high
variation across the user base.
The GUI builder might start by asking (1) how many buttons (2) how many fields.
Then for each button :
script name,
label,
error message table (based on script results)
and for each data input a script name.
Every input field would have a corresponding error message field.
I suggest using Mod Auth MySQL for user password authentication.
http://freshmeat.net/projects/mod_auth_mysql/
here's the list provided by d.loss (of pre-existing efforts) :
http://basmati.sourceforge.net/
http://people.westminstercollege.edu/students/d-b1649/programming/php/bessie.html
http://sourceforge.net/projects/edubase/
http://mainline.essi.fr/wiki/bin/view/Eis/http://utstorm.sourceforge.net/
http://Ggradebook.sourceforge.net/
http://carol.wins.uva.nl/~zegerh/grades/
http://gradeview.sourceforge.net/
http://sourceforge.net/projects/ioniastudent/
http://www.lightandmatter.com/ogr/ogr.html
http://www.opensis.org/
http://utstorm.sourceforge.net/
NEXT STEP :
Do a "markup" of existing Storm inputs and outputs, from which a
determination of the level of effort can be made.