Re: [WWdevel] Config module questions

[John J. <jj...@as...>]

Michael Gage wrote:

>
> On Sep 29, 2005, at 7:11 PM, John Jones wrote:
>
>> Hi,
>>
>> There was previous discussion of a web-based course configuration  
>> module.  I have a draft of this, but also a couple of questions.
>>
>> First, the module knows what values can be configured (and how) via  
>> one variable which looks like this:
>>
>> [['General',
>>        { var => 'sessionKeyTimeout',
>>          doc => 'Inactivity time before a user is required to login  
>> again.',
>>          doc2 => 'Length of inactivity, in seconds, before a user  is 
>> required to login again.',
>>          type => 'simple'},
>>        { var => 'courseFiles{course_info}',
>>          doc => 'Name of course information file',
>>          doc2 => 'Name of course information file (located in the  
>> templates directory)',
>>          type => 'simple'}],
>>    ['Permissions',
>>        { var => 'permissionLevels{login}',
>>          doc => 'Allowed to login to the course',
>>          type => 'permission'}, ...]]
>>
>> Adding variables which can be configured will amount to adding  
>> entries to this constant.  The first question is, where should this  
>> go?  Should it be a constant in the new module, or should it be in  
>> Constants.pm, in which case configuration would be "configurable".   
>> Both ways are easy to work with, so I don't really care myself.
>>
> Hi John,
>
> I guess I vote for Constants.pm, but I don't have a strong preference.
>
> It's not completely clear from your description...
> Does your scheme above allow one to specify the values and perhaps  
> labels of those values that a variable can assume?
>
> What I have in mind is a form element for permissions that has a  
> popup menu with    guest, nobody, student, ta, prof as labels
> and -5, undef, 0, 5, 10 as values.  Having the allowable values  
> configurable will probably be useful.
>
> There will be other examples where it will be best if the instructor  
> is allowed to choose among specified alternatives rather than
> enter values free form.
>
I didn't include the full configurations part, but there is enough to 
see that each variable has a type, and permissions is one of the types, 
so it gets special handling.

One problem with permissions is that the value of things like "ta" is 
configurable in global.conf, but the value is not visible from the 
outside.  One change I was going to make in global.conf.dist was to add 
to the permissions structure:

%permissionLevels = (
        login                          => $guest,
        report_bugs                    => $student,
...
        guest     => $guest,
        student   => $student,
        proctor   => $proctor,
        ta        => $ta,
        professor => $professor,
);

This way, the numeric value of ta is known to the Config module.  The 
config module then handles permissions with an official webwork combobox 
which shows both the name and numeric value in the menu part.  I thought 
this was better than just name because it lets users set other crazy 
permission values if they want (which is the current situation), they 
can see qualitatitively what the numbers mean, but they have the numbers 
which is what they see on the classlist page.  With this change, 
however, the classlist page could switch to names for permissions if the 
numeric value matches one of the values for standard names.

The current types are 'simple' (a text string), 'permission', 'list' (a 
list of text strings like feedback e-mail addresses), and 'boolean' (for 
things like useOldAnswerMacros and useBaseTenLog where Config translates 
back and forth between a drop-down menu of true/false and 0/1 for the 
variables).  Adding other types will not be very hard, but would require 
changes to the module itself.

John

PS HTML::ComboBox::combobox allows a second argument of @Records which 
doesn't seem to be used.