[ww-bugs] Bug 3454: includePGfile

Sun Sep 20 18:11:10 EDT 2015

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

--- Comment #3 from Davide P. Cervone <dpvc at union.edu>  2015-09-20 18:11:09 ---
> note that includePGproblem() and includePGfile() behave differently

Indeed.  Note that includePGfile() predates includePGproblem() by probably 5
years, so the unionInclude.pl macros couldn't have used includePGproblem(),
which didn't exist, so I wrote my own.  I suppose includePGfile() could be made
to use includePGproblem() now that it exists.  (I do note, however, that
includePGproblem() seems to set up its own PG_alias object, so it looks like
using includePGproblem() won't track resources?)

> includePGfile( file_name assumed to be in the same folder as original .pg file)

It's actually includePGfile(name relative to directory of original file).  It
doesn't have to be in the same directory.

> If a problem using includePGfile is saved as a local problem then the link to
> the included file is broken (it is no longer in the same directory).

True, but this is also the case for things like images and other files that are
stored in the same directory. (Note that there are things other than images,
like files for LiveGraphics3D, and I presume other applets could load files
locally.  You can also have local macro files, like the one in setOrientation).
 Making a local copy of one of those problems also means the file will break
unless you copy the auxiliary files as well.  This is certainly consistent with
how things work.

I wasn't aware that the library browser doesn't let you edit the -text.pg
files, but I can see why that is a good thing.  Personally, I think the
solution to that is to allow set the valid_symlinks variable to allow the File
Manager to traverse the Library hierarchy, so you can use the file manager to
copy the file if you want.

If the PGproblemEditor were to copy the auxiliary resources when it saves copy
of the pg file (perhaps it does now), then the solution would be to have
includePGfile add its file to the resource list.  Perhaps that is what the new
# RESOURCES tag does?  (Of course, none of that was available when
unionInclude.pl was written).

> using  includePGfile("../included-text.pg") wouldn't work either

I don't think that is the case.  The code does handle double-dot relative
locations.  But it finds the starting directory from $envir{fileName}, and I
don't know what that looks like for your HTML page setup.  If $envir{fileName}
was dir/prob2/prob2.pg, then it should properly locate dir/included-text.pg via
includePGfile("../included-text.pg"). 

> unionIncludes.pl  occurs in both macros/Union and macros/CollegeOfIdaho.

Note that macros/CollegeOfIdaho includes duplicates of many of the Unionmacros,
as well as a large number of obsolete Union macros, and some standard PG macro
files.  It really needs to be cleaned out.

> The biggest problem is that includePGfile() assumes that the pg file path
> originates in the template directory of a course

Note that incudePGproblem() also does the same.  The only difference is that
includePGproblem() takes the file name as relative to the templates directory
itself, and incudePGfile() takes it as relative to the directory of the PG
file.  In the normal WeBWorK interface, $envir{fileName} is relative to the
templates directory.  I don't know what it looks like for the command-line
interface or the HTML page interface.  

> includePGfile is searching for the target file on the server (with standard directories)
> not on my laptop

The includePGfile() macro uses $main::templateDirectory to find the directory,
so it may be that that isn't set up properly by the command-line tool.  Note
that includePGproblem() uses $envir{templateDirectory}, so it should do the
same (I'm assuming these two variables are in synch?).

> 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

This is also consistent with other material included in the problem (e.g.,
images, local macro files, etc.).

> 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 ... because I think it will be slightly more robust.

I would object to that, as it is simply exchanging one robustness problem for
another.  In my opinion, having a problem in one directory use an absolute
address to access a file in another directory (or in the library) would be bad
practice.  The files needed for a problem should be kept in the same directory,
and if you make a new copy, you should copy the files, not link to them in some
other place (where they can change or be removed without any realization that
some other problem is using them).  If you make a new version of a file and
don't copy the files, it SHOULD break, in my opinion.  That is what tells you
that you need to copy the auxiliary files.  If we can have tools like #
RESOURCES that help make copies of them automatically, then that is the
solution, not changing the addresses to absolute ones so that everyone's
hierarchy must be the same.

> 1. It means you don't need the hack for removing the tmpDir prefix which is
> added while the file is being edited.

Has this been a problem for anyone?  I don't see this as a serious issue.

> 2. It allows for referencing a target file which is one level up. (see case 3. below) 

I don't think 3 is actually an issue if the $envir{fileName} is set properly
(as a relative address from the templates directory).  If this is set to
something else by the command-line or HTML-page interface, then I would suggest
that perhaps normalizing how $envir{fileName} is set up might be a better idea.

> 3. It also means that the addressing system used in includePGfile() and
> includePGproblem() will be the same.

If you want that, then you might as well remove includePGfile() and replace it
with includePGproblem(), as they are essentially identical otherwise.  Delete
the body of includePGfile() in unionInclude.pl, and have it call
includePFproblem() directly and you are done.

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