Re: [WWdevel] Config module questions

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

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?

John