draggableMacros.pl migration and javascript support about pg HOT 5 OPEN

In my opinion, using different versions of PG and WW2 is a mistake, and is a practice that should be strongly discouraged. This is one problem that can be caused by it. There are other issues that are going to probably start to occur also. Generally speaking, in order to move forward with many features there is going to be some tighter integration needed between the pg and webwork code. MathQuill answer boxes is one of those features that really needs this to really make it work the way that some want it to. Particularly in regards to contexts and answer types and controlling behavior of what is typed in a MathQuill answer box. The TikZ image code also has changes that were made both in the pg and webwork code. I have other planned changes that will also need to make changes on both sides.

To be a bit frank (although hopefully not offend those that made this decision), I don't think that it is really a good idea to have pg and webwork code in different code repositories.

from pg.

from pg.

The other reason to have pg separate from webwork2 (and if possible even more separate than now) is so that PG can operate with things like sendXMLRPC and standaloneeditor and eventually as a direct LTI plugin to an LMS.

In my opinion this is actually an argument that the webwork2 and pg code should be together. The pg code does not have any of the infrastructure that will allow for the things that you are talking about, and the webwork2 code does. In order to make the things mentioned work with pg directly, it will be necessary to put things that are being done in the webwork2 code into the pg code. This is not a matter of keeping the code separate, but rather is moving webwork2 code to the pg side. Alternatively, the things mentioned would be much easier to implement from the webwork2 side by creating new interfaces that utilize existing code.

This is actually an argument for keeping the PG problem javascript code in the course or pulling it from a CDN. Long term we could start a pg/js directory which is searched for js requests originating from within pg problems. As we use more javascript in problems this might be advantageous.

It would be a good idea to have a separate location for javascript libraries (and css files) that are used purely by PG macros that are in the repository, and kept in the PG repository in say a pg/htdocs directory. Currently the only option for adding a macro to the PG repository that uses javascript is to put the javascript in the webwork2/htdocs/js directory (or pull from a CDN). There is no available location for the PG repository that is http accessible.

Note that pulling from a CDN is not a possibility if the javascript library used by the macro is specifically created for the macro, and is not something that is available in any CDN.

from pg.

_> draggableProof.pl (currently living in OPL/macros/MC/) has a hardcoded reference to webwork2_course_files rather than webwork2_files, meaning that anyone who wants to use draggableProof has to store a local version of the javascript.

The draggableProof macro currently lives in the OPL, and should probably be migrated here, to PG; and along with that, the associated jQuery module should also be included in the webwork2/htdocs/ tree.

I don't know how worried we should be, but the suggested migration poses a potential issue:

* suppose a site upgrades PG without upgrading ww2

* draggableProof macro from PG now has priority over macro in the OPL

* the PG macro points to the global webwork2/htdocs/ location

* but unless ww2 is upgraded along with PG, the requested jQuery module is missing

* situation cannot be remedied (as it is now) by adding the jQuery module to the course/html location

_
This is true, but it's not a complete deal blocker since a professor can add a copy of the original draggableProof.pl macro
(currently in OPL/macros/MC) to their template/macros directory and change the javascript reference to a cloud based version of 'nestable'. Not a perfect solution but it would work for many use cases.
(see #516 )

looking for suggestions on handling this migration... I've tried testing for the existence of the javascript file from within the draggableProof.pl macro, but WWSafe prevents file tests such as if (-e $file_path) { ... }.

I think this is worth considering for other reasons as well. I'm not sure why -e was considered dangerous -- for the most part we following guidelines in OpCode.pm

from pg.

Solved (for now) by #516 but using a CDN source.

Some of the discussion bears further consideration, so I'm not closing it now.

from pg.