[ww-bugs] Bug 3454: includePGfile

[bugzilla-daemon at webwork.maa.org]

http://bugs.webwork.maa.org/show_bug.cgi?id=3454


Mike Gage <gage at math.rochester.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED




--- Comment #2 from Mike Gage <gage at math.rochester.edu>  2015-09-19 22:12:51 ---
More information.  

The includePGfile() problems work just fine in general when called from an HTML
page. Those questions are called through a specific course (e.g. daemon_course)
and as long as the problem called is in the Library (or in the daemon_course)
includePGfile() will find companion file to be included.

This will probably not work, in general, if the HTML page problem is including
the text of the PG problem using base64 encoding since there is no enclosing
directory in that case.  It's still possible to include a path to a file when
submitting a base64 encoded problem so it still might be possible to target an
auxiliary file that is in the daemon_course (or Library). This seems to be
pretty fragile.


The use case that fails at the moment is when the PG problem is rendered from
the command line:

wwperl renderProblem.pl
/Volumes/WW_test/opt/webwork/libraries/webwork-open-problem-library/OpenProblemLibrary/Union/setIntRiemannSums/an6_4_31_right.pg

gives the error: 
Can't read file
[TMPL]//Volumes/WW_test/opt/webwork/libraries/webwork-open-problem-library/OpenProblemLibrary/Union/setIntRiemannSums/an6_4_30-define-function-text.pg
at [PG]/lib/WeBWorK/PG/IO.pm line 139

The biggest problem is that includePGfile() assumes that the pg filepath
originates in the template directory of a course, which seldom the case if you
are editing a pg problem independently from the command line.  Another issue in
my case is that the local directory structure on my laptop doesn't follow the
standard /opt/webwork/webwork2 structure and includePGfile is searching for the
target file on the server (with standard directories) not on my laptop.  

The fact that includePGfile() uses relative addressing is nice in some ways
since that means that the location of the file can be changed without modifying
the problem itself (as long as the companion file is moved in the same way). 
On the other hand the way that the relative addressing is changed to the full
address depends on assumptions that are usually, but not always, satisfied. 

It's not a big deal either way, but I'm leaning toward changing includePGfile()
to use relative addresses which are relative to the template directory of a
course e.g. Library/Union/setIntRiemannSums/an6_4_30-define-function-text.pg
because I think it will be slightly more robust. 
1. It means you don't need the hack for removing the tmpDir prefix which is
added while the file is being edited.
2. It allows for referencing a target file which is one level up. (see case 3.
below) 
3. It also means that the addressing system used in includePGfile() and
includePGproblem() will be the same.

-- 
Configure bugmail: http://bugs.webwork.maa.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.