← Back to branch summary

~azzar1/unity/add-show-desktop-key

« back to all changes in this revision

Viewing changes to doc/notes/misc.txt

  • Committer: matt.giuca
  • Date: 2009-01-14 10:10:12 UTC
  • mto: This revision was merged to the branch mainline in revision 1090.
  • Revision ID: svn-v3-trunk0:2b9c9e99-6f39-0410-b283-7f802c844ae2:branches%2Fstorm:1132
The new ivle.database.User class is now used in Request and usrmgt, which
    means it is now almost universally used in favour of ivle.user.User (now
    deprecated).

Noticeable change: The minor bug where the change to a user object in the
    database is not reflected in the user's session (eg. changing nick doesn't
    update title until log out).

ivle.dispatch:
    Session now contains 'login' (username string) rather than 'user' (full
        ivle.user.User object). This is a unicode string now.

    req.user is now a ivle.database.User object rather than an ivle.user.User
        object. This makes for a whole lot of really subtle differences, but
        largely conforms to the same interface. Note that strings must now all
        be unicode.

    login: Removed use of ivle.db. Now uses User object.

    html: Now handles unicode login and config options.

ivle.db: Removed update_user. Now replaced with Storm model.

ivle.database: Renamed has_cap back to hasCap (saved for later). Fixed small
    unicode bug.

ivle.makeuser.make_svn_auth now takes a store object.

usrmgt-server: Use new User class.

userservice: Now uses User class internally.
    get_user action now returns ISO 8601 date format, rather than a
        time tuple. (Wasn't being used).
    get_user action no longer transmits local_password (small security risk;
        note that it wasn't possible to see this for any user other than
        yourself unless admin).

ivle.util - added function object_to_dict.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/notes/misc.txt
 
1
IVLE Design - Misc
 
2
==================
 
3
 
 
4
    Author: Steven Bird, Matt Giuca
 
5
    Date: 4/12-7/12/2007
 
6
 
 
7
Tutorial page
 
8
-------------
 
9
 
 
10
Tutorials need to be able to include and submit not just Python code, but any
 
11
arbitrary HTML form (such as option buttons to answer multiple choice
 
12
questions, or non-EditArea text fields).
 
13
 
 
14
Specification
 
15
-------------
 
16
 
 
17
* includes marking scheme
 
18
 
 
19
Submission
 
20
----------
 
21
 
 
22
* student: commits against a tag specific to a project
 
23
* we do an svn rm of whatever is there; then an svn copy
 
24
* we do a checkout of this tag on the submission deadline
 
25
* this creates a working copy that the individual student and the
 
26
    staff members can see
 
27
* student can navigate to their submission to verify it
 
28
 
 
29
Verification
 
30
------------
 
31
 
 
32
* to permit automated verification of an interactive submission, need
 
33
    to design the project specification so that we can make assumptions
 
34
    about field names, so we can test the submission using a GET request
 
35
* response could be HTML; easy to capture
 
36
* response could be a redirect to an image (won't follow img tags)
 
37
* unresolved issue re printing
 
38
* public tests that everyone can see; additional tests only seen by assessors
 
39
 
 
40
Workflow for assessor
 
41
---------------------
 
42
 
 
43
* sees a page of links, each for some test case
 
44
* sees peer reviews of this submission to help find issues
 
45
* sees peer reviews by this student which are assessed
 
46
* marking scheme and comment boxes, and mark boxes available
 
47
 
 
48
Peer review
 
49
-----------
 
50
 
 
51
* just another marking scheme (less detailed, more comment field-based)
 
52
* possibility of peer review in a multi-stage project; first stage can
 
53
    be assessed and fully exposed to peer reviewer, later stages can use
 
54
    anyone's implementation of the earlier stages
 
55
 
 
56
Tutorial exercises
 
57
------------------
 
58
 
 
59
* permit comment thread on each exercise
 
60
* other students permitted to score comments for usefulness
 
61
 
 
62
Relationship between verification and checking tutorial exercises:
 
63
 
 
64
* want to categorize mistakes and give hints