Re: [WWdevel] Config module questions

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

On Sep 29, 2005, at 19:11, John Jones wrote:

> 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.

Constants.pm sounds like a good place for this.

> The saving of information is done at the end of course.conf after a  
> comment line it adds as a separator.  Writing to course.conf will  
> mean preserving the stuff above its separator, and then writing  
> values which are needed below the separator.
>
> 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.
>
> I am getting the values of variables by firing up multiple course  
> environments.  You have the current course for free, and one can  
> easily get the system defaults by WeBWorK::ContentGenerator->new  
> with no course specified.
>
> But, to easily know what the values would be if we only had the top  
> part of course.conf, I would like to be able to specify the  
> course.conf file while creating a new CourseEnvironment object.   
> Then I could write the top half of course.conf to a file named  
> something like course-config-tmp.conf and use it for a new course  
> environment.  I want to use that to create a course environment,  
> and then delete it.  So far, my attempts have failed (to give the  
> current course as the course name but to have course-config- 
> tmp.conf be used as the course configuration file).
> I could work around it by making a copy of course.conf, replacing  
> it with the top half, creating a course environment, then moving  
> the original course.conf back into place, but I would rather not  
> make so many changes to course.conf.
>
> So, is there a way to have WeBWorK::CourseEnvironment->new be  
> tolded the name of the course configuration file for the current  
> invocation?
>
> If not, would anyone mind if I added that feature to  
> CourseEnvironment.pm (specified through the hash reference way of  
> specifying arguments)?

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. This would  
also save you from having to calculate the values for "this course  
minus anything previously set by this module". 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.

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.
>
> 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 think there are times in a project's life cycle when you don't  
> know what your users are going to want, but you do know that they  
> will be sophisticated early-adopters, and so you make your system  
> turing-complete.  but at some point common usage patterns appear  
> and you can start to make them more static.
>
> I have a secret agenda here that course.conf eventually stops being  
> user-edited.
>
> a TC config file is useful, but for non-technical users, it starts  
> to feel like a cop-out for inadequate user testing.

And:

> you don't have to think of yourself as making that distinction  
> [between beginner and advanced users].  The distinction isn't  
> present in the GUI.  I mean, all open-source code makes that  
> distinction.  The regular users edit the config files, the advanced  
> users edit the program.
>
> I'm saying, course.conf becomes part of the "source code" of the  
> program, slowly but surely as you learn what kinds of configuration  
> people actually want to do.

Imagine a machine-readable and -writeable representation that would  
be stored somewhere. (file? database? whatever.) It could be  
something as simple as a set of key-value pairs, or a Data::Dumper  
string. CourseEnvironment would read it in, and Safe::share() the  
values contained in it into the compartment that

I think this would be good for flexibility, but there are  
bootstrapping problems. Namely, the only thing we know before the  
course environment gets built is the path to the webwork base  
directory (and we assume "conf/global.conf" relative to that), so it  
would be impossible to store the config information under the course  
directory, for example.

Brainstorming...

One solution would be to pull the database config out of the course  
environment and make it static (Constants.pm or passed in from the  
apache config or something). Since we're planning on removing all but  
sql_single for 2.2 anyway, this would be doable. Then, the "simple  
config" information could be stored in a settings table, and used to  
seed the course environment before evaluating global.conf.

Another possibility is to let global.conf decide when to load the  
simple config data. It could get loaded from a file in the course  
directory after the initial values are defined, because by that time  
the loader would have access to $webwork_courses_dir.

Comments?
-sam