From: Michael G. <ga...@ma...> - 2005-09-29 23:40:37
|
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. Thanks for working on this. It looks like a good start. Take care, Mike > 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)? > > Of course, other comments/suggestions are welcome. > > John > > > > > ------------------------------------------------------- > 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." |