Menu
▾
▴
Re: [WWdevel] Config module questions
|
From: Michael G. <ga...@ma...> - 2005-09-30 01:14:16
|
On Sep 29, 2005, at 8:42 PM, John Jones wrote:
> 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
>
If you add a key/value pair type then I think you cover everything
I can think I would want. The boolean is already a key/value pair.
And some versions of email addresses might involve key/value pairs:
e.g. user_id/user_email_address. You'd use the key
as a label in a popup menu and the value as the vaule.
I'd like to suggest that for the first approximation you assume that
the "upper" part of the course.conf file is empty.
What I would hope is that when we first implement your module there
are the site configurations in global.conf
and anything that we currently override in any of our installations
for course.conf can be written in the lower part of course.conf.
Instructors would be discouraged (perhaps prevented) from adding
things directly to course.conf via File Manager.
Eventually we'll find something complicated that has to go in
course.conf but can't easily be handled by the mechanism you've
defined and it will have to go in the top part of course.conf. Then
the more general paradigm you're talking about will be useful.
At the beginning however I'd like to keep the top part either empty
or very small.
About permissions. Eventually I'd like to use strings for permission
values rather than integers. Permissions would also form
a partial ordering instead of a linear ordering (or perhaps a more
general structure). That's for the far future however.
Take care,
Mike
> PS HTML::ComboBox::combobox allows a second argument of @Records
> which doesn't seem to be used.
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> OpenWeBWorK-Devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openwebwork-devel
>
"Only dead fish swim with the stream."
|
