Re: [WWdevel] Config module questions

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

Hi all,

I just an initial version of the Config module.  Based on the earlier 
suggestions, I used a separate file for the simple config parts; it will 
not write to course.conf at all.  I would not expect it to be too hard 
to store this information in a database instead.

There are tons of variables which can still be added.  Most of it can be 
put right into the variable at the end of Constants.pm (e.g., there are 
over 40 permissions values and I only did a few of them).  Feel free to 
start adding to it.  Other items will require new config-types to be 
added to the module itself, so naturally it would be simpler to add 
where one can use an existing type.

John


Sam Hathaway wrote:

> On Sep 30, 2005, at 1:58, John Jones wrote:
>
> What you propose is probably fine for the kind of customization we  
> want to allow right now. Here's my thinking, though:
>
> * I want to be able to use web-based (i.e. non-turing-complete)  
> configuration for things that site administrators might want to  
> configure. Look at moodle -- there are many per-course options that  
> can be configured, but system-wide admin-type options are also exposed.
>
> * We can't predict what kinds of options administrators (or even  
> users) are going to want to customize.

At first I was thinking of this doing something for global.conf, but 
then backed off.  If someone develops a global.conf analogue, then they 
will have more complicated issues to deal with.  Still, they can 
probably make life easier for sites by making some things 
web-configurable.  I might still shy away from allowing 
web-configuration of values which can make the whole system unusable.

As far as what users want to configure, I expect that the configurable 
options will grow over time, partly due to user requests.  But, there 
may be some options users have to configure by hand.

> * I want global.conf/course.conf to become more like source and less  
> like configuration over time.

I think this is consistent with the current setup.  While the new 
"simple.conf" is read by perl, it could work in other ways.  Read by 
perl was the simplest way to incorporate it into the current system.

> On the other hand, your method is simpler and doesn't have  
> bootstrapping problems, so I would say that you should go ahead with it.
>
> On Sep 29, 2005, at 19:11, John Jones wrote:
>
>> To know what values to write, the module will figure out what the  
>> system defaults are, the values for this course, and the values for  
>> "this course minus anything previously set by this module".  The  
>> last one is needed to prevent odd behaviour if course.conf differs  
>> from the system default in its upper part and the user switches  back 
>> to the system default.  This may be a rare occurance, but if  we can 
>> check for it, we might as well.
>
>
> Why not enclose the stuff written by the Config.pm module in a  
> conditional like
>
> unless ($skip_config_pm) {
>     ...
> }
>
> and then call WeBWorK::CourseEnvironment->new(..., skip_config_pm => 1)?
> -sam