Menu
▾
▴
Re: [WWdevel] links to problem libraries
|
From: John J. <jj...@as...> - 2006-02-07 21:27:22
|
Hi,
Having a mechanism to specify a path which is not under templates seems
like a good idea, and better in general than the current mechanism used
by the database_problems.
One note on the current database_problems approach - it only makes the
link when you try to access the "Problem Library" part of the "Library
Browser". It should also handle the situation where a problem is looked
for and not found. This can happen when you import a set with problems
from the database_problems, but haven't accessed them through the
Library Browser in that course yet. I don't know if I made that clear.
John
Sam Hathaway wrote:
> On Jan 16, 2006, at 21:32, Michael Gage wrote:
>
>> Hi all,
>>
>> I've had some difficulties describing the process of adding new
>> problem libraries to other webwork system admins.
>> The problem is retroactively adding links to the problem libraries
>> from the templates files of the existing courses.
>>
>> For new courses, I simply add the links to the modelCourse and copy
>> that whenever I make a new course.
>> For the old courses I have written a script, but it's not that
>> robust or portable.
>>
>> The nationalLibrary (or database_problib or whatever name you wish
>> to use) automatically adds a link if its missing.
>>
>> I was thinking of adding some information to global.conf, so that
>> something similar could be done with the other problem libraries.
>> I'd replace
>>
>> $courseFiles{problibs} = {
>> rochesterLibrary => "Rochester",
>> rochester_grade8Library =>"Rochester grade 8",
>> asuLibrary => "Arizona State",
>> dcdsLibrary => "Detroit CDS",
>> dartmouthLibrary => "Dartmouth",
>> indianaLibrary => "Indiana",
>> nauLibrary => "Northern Arizona",
>> osuLibrary => "Ohio State",
>> capaLibrary => "CAPA",
>> unionLibrary => "Union",
>> tcnjLibrary => "TCNJ"
>> };
>>
>>
>> by
>>
>> $courseFiles{problibs} = {
>> rochesterLibrary => { name => "Rochester", path=> '/ww/webwork/
>> rochester_problib'},
>> rochester_grade8Library =>{name=> "Rochester grade 8", path => '/
>> ww/webwork/rochester8thgrade_problib'},
>> ... etc.
>> };
>>
>> With this structure we could later add more information about each
>> library if that was needed.
>>
>>
>>
>> Does anyone see downsides to this? Should we just encourage the use
>> of scripts, and perhaps write some robust ones?
>> Does anyone have better/different ideas about this?
>
>
> Hi Mike,
>
> This looks good to me. I'm for courses being "self-healing" in some
> ways. For example, creating temp directories as needed. I don't see a
> problem with auto-creating symlinks, as long as we do it securely and
> are careful not to overwrite existing files/symlinks.
>
> At some point we might want to stop using symlinks to get to problem
> libraries, and instead access them directly, and the $courseFiles
> {problibs} format you propose allows for that.
>
> The only downside I can think of is that some courses might want to
> "opt out" of access to problem libraries, perhaps to speed up
> traversal of the templates directory. But this could be achieved by
> adding "delete $courseFiles{problibs}{some_problib}" to that course's
> course.conf.
>
> When we implement this, we should use the same symlink-generating
> code for both the regular problem libraries and the database problem
> library, if possible.
> -sam
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> OpenWeBWorK-Devel mailing list
> Ope...@li...
> https://lists.sf.net/lists/listinfo/openwebwork-devel
|
