Re: [OpenWeBWorK-devel] WWDBv3

[Michael G. <ga...@ma...>]

>
> I've added display_mode, show_old_answers, show_correct_answers, 
> show_hints, and show_solutions columns to the users table, with the 
> caveat that we might not want to allow normal students to set the 
> latter three.
>
> I wonder if, in addition to this per-user default (set in User 
> Options), we should make it so that if a user explicitly sets one of 
> these options in a problem's View Options panel we save those options 
> for that problem only, with an option to "reset to defaults".
>
I would say that the last three options should be on a problem_user 
basis.
Even the first two might be on a participants rather than a user basis 
(if I've understood participant.  Ones choice of
display mode might be different in different courses.)
I would suggest that the data could be present in any one of those 
databases, and the software (or the database itself)
would have fall back options from  problem_participant to participant 
to user.

>> This would be mean that as a rule the only state that needs to be 
>> passed from one webpage to another in hidden
>> variables would be "user", "key", "course", "set", "problem",  and 
>> possibly a few other specialized hidden variables
>> used when a page calls itself and wants to indicate success or 
>> failure.
>
> The only hidden variable that we'll need on a regular basis is "key", 
> since "course", "set", and "problem" are encoded in the URL and "user" 
> can be stored in the session (which could map key -> [ user, 
> timestamp, etc. ]).
>
Right.

> It's somewhat dangerous to store certain data in the session object, 
> as it could prevent the user from performing multiple concurrent 
> operations in the same session. For example, if we wrote the editor to 
> store unsaved source for preview in the session, then this could 
> happen:

> The professor starts editing a problem, and then previews it in a new 
> window (preview A). She then continues to edit and previews it in 
> another new window (preview B). If she then goes back to preview A and 
> attempts it, her submissions will be compared to the version of the 
> problem in preview B, and that version will be displayed when the page 
> loads.
>
Actually I believe that is the way it works now. And we can tolerate 
the discontinuity.  But I see your point.

> (Of course, it's OK to store preference data in this way because 
> there's no need for concurrency there. But the UI has to make it clear 
> that it's a preference.)
>
> We can store things that would cause problems as above in the session 
> as long as they're uniquely identified in some way. If the editor 
> assigned a unique ID to each version of the source previewed, and then 
> that information was passed to the editor in the request, we wouldn't 
> have the problem above. On the other hand, then you're carrying around 
> another (shorter) param in the request.
>
We can do this up to a certain point, but we need to balance the 
complexity against the usefulness and the maintainability.

> (The logical extension of this is just keeping the process's stack in 
> the session, i.e. continuations.)
True.  That's probably going too far. :-)

Take care,

Mike

> -sam
>
>