Re: [WWdevel] Config module questions

[Sam H. <sh...@ma...>]

On Sep 30, 2005, at 1:58, John Jones wrote:

> Sam Hathaway wrote:
>
>> What do you think of having these values pre-seed the course   
>> environment, rather than being tacked on at the end? This would  
>> let  us incorporate them into inline logic in global.conf, which  
>> would be  useful in cases where one value is used in several places.
>
> I guess I haven't run across any places where this savings would  
> take place.  Mostly, we are just assigning to variables, and so the  
> last assignment wins.  Pre-seeding seems like it would be more  
> complicated since setting the global values would have to check to  
> see if a course value was pre-seeded set.
>
>> This would  also save you from having to calculate the values for  
>> "this course  minus anything previously set by this module".
>
> I'm not sure it saves anything.  I think the same problem exists if  
> you pre-seed, and you have the analogous set of solutions (not  
> worry about user edits in course.conf, just save all values  
> regardless of whether they seem to differ from system defaults, and  
> figure out the three values of system, upper-part of course.conf,  
> and lower-part of course.conf).
>
>> Also, it would avoid  having to rewrite user-editable text files,  
>> which, while I'm sure it  could be done relatively sanely, make me  
>> nervous.
>
> I think it would be trouble if Config had to parse course.conf  
> itself and try to rewrite portions which contain might have  
> contained tricky things in it.  In the current approach, neither of  
> those things happen.  The use of CourseEnvironment means that  
> values are computed by the existing mechanisms.  You can be as  
> tricky as you want in the top half of course.conf.  In will be  
> rewritten only in the sense of transcribed verbatim.  Writing the  
> bottom half of course.conf would be straight variable assignments,  
> and it would only write variables it has been taught to write.  The  
> only part of that which makes me nervous is for string values where  
> you want to protect the user from unbalanced quotes.
>
>> Dennis's take on the subject:
>>
>>> You define a limited set of configuration options that most   
>>> "simple" users will want.  Then you develop a simpler config  
>>> file  format for describing those options and put a GUI on it.   
>>> Then you  write a course.conf file that reads that file (or is  
>>> given the data  inside via a stream or something for security  
>>> reasons) and sets the  appropriate values based on it.
>
> This seems equivalent to the approach I was taking.  The only  
> difference is whether simple settings are in a separate file, or  
> part 2 of course.conf.  The advantage of using course.conf is that  
> it gets read on every web page webwork renders, so reading one few  
> file is a fraction of a second faster.
>
> If you do have a course.simple which gets read after course.conf,  
> it would still be helpful to have a mechanism to say: make a  
> CourseEnvironment object where you do not read course.simple.  This  
> seems to be pretty similar to: make a CourseEnvironment with this  
> file as course.conf.
>
>>> For the things that involve the setting of a string and then the  
>>> subsequent using it all over, you could just define fields for  
>>> the  various parts and have the string concatenation be implicit  
>>> from  the point of view of the configuration.
>
> I don't think we want to let a user set $webworkDirs{logs} or  
> $courseURLs{html} through the web-based configuration.  I looked  
> through global.conf.dist and I don't see any variables on the right  
> side of an assignment which a regular user should be able to  
> change.  Are there some others have in mind?

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.

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

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