Integrate GUIWorK with WebWoK

[SchmidtNikolas]

GUIWorK is a standalone system: The PGML code it generates must be copied-and-pasted into WeBWorK, and previously generated problems must be copied-and-pasted back to GUIWorK if point-and-click editing is later desired.

[SchmidtNikolas]

Looks like the WeBWorK 2 repo has a htdocs/js/apps/vendor path that we can use to save external/vendor JavaScript (that is, GUIWorK) into. Then we'll have to load it into PGProblemEditor2.pm and/or PGProblemEditor3.pm using CGI. Not super familiar with Perl syntax, but maybe we can make a simple Perl module to run GUIWorK (as we do with the initial Generate.html and Edit.html) and import that into the page. Probably going to prioritize this, that way we can do all future work from inside of WeBWorK itself.

[SchmidtNikolas]

I've been making changes and having difficulty viewing them, even on local. Turns out it was a Docker thing. Hitting myself in the head for being a dummy, but at least I made myself more familiar with Docker. Nothing too big to report other than that for now.

[SchmidtNikolas]

@drjeffjackson So I went ahead and changed dev branch into a verison of the webwork2 repo and I'm slowly working on integrating the GUIWorK interface into things. This helps us keep up to date with the live version of webwork2 since we can add it as a remote and pull from that too. To run this version, you can basically:

1. Pull this into a machine with Docker installed. (More details here.)
2. cd workingdir
3. docker build .
4. docker-compose up

All the GUIWork stuff is currently living in htdocs/js/vendor/GUIWorK. I've added an initialize.js file to start loading everything into the web page to try to avoid deleting anything that exists at this point. I'm using some jQuery because that happens to have been adopted by the WeBWorK team. I think next step is to start having this read the textfield and parse out anything it can as JSON into options for the GUIWorK menu. As I see it, GUIWorK should:

• Parse the problem's text to JSON for rendering in a GUI
• Load the rendered data into the GUI with options set appropriately.
• Have a button to submit everything that re-writes the problem to the text field

Then all saving and everything can be handled by WeBWorK core. This will also save us some time from having to make a separate tool involved with converting different GUIWorK problem versions.

Let me know what your thoughts on this are. I'm not sure if this is too serious a change for you or what.

[drjeffjackson]

Looks like the WeBWorK 2 repo has a htdocs/js/apps/vendor path that we can use to save external/vendor JavaScript (that is, GUIWorK) into.

I think that the vendor folder is meant for external libraries like bootstrap. It seems to me that we should create a GUIWorK folder under apps. Alternatively, per the js/README_js_organization, we could create an app-dev folder under js and create GUIWorK under that. But I lean toward the former approach.

[drjeffjackson]

All the GUIWork stuff is currently living in htdocs/js/vendor/GUIWorK. I've added an initialize.js file to start loading everything into the web page to try to avoid deleting anything that exists at this point.

I'm not seeing the initialize.js or much else in the way of changes. I don't seem to be able to click on the GUIWorK folder itself. I can click on the commit message "Integration with WeBWorK." which takes me to commit 208927b8ef52af5d2db69b54bc658c0e212e3856.

Also, there are lots and lots of whitespace differences in the two .pm files of this commit, which makes it very difficult for me to tell whether or not there are any substantive changes in these files and, if so, find them. Not sure what PR reviewers will think about this. Thoughts?

[drjeffjackson]

maybe we can make a simple Perl module to run GUIWorK (as we do with the initial Generate.html and Edit.html) and import that into the page. Probably going to prioritize this, that way we can do all future work from inside of WeBWorK itself.

Sounds like a good plan. An alternative would be to create a PGProblemEditor4.pm, since this is in some ways a very different editor. But I think that this would involve a lot of duplicated code, unless maybe shared code could be factored out of PGProbEd2 and 3 and also used by 4.

[drjeffjackson]

I'm using some jQuery because that happens to have been adopted by the WeBWorK team.

Adopted as a standard for others to follow? Can you please supply a reference? Unless it's specified as a standard that we're supposed to follow, I'd prefer that we use straight ES2017.

[drjeffjackson]

I think next step is to start having this read the textfield and parse out anything it can as JSON into options for the GUIWorK menu.

Do I understand correctly that you're proposing writing a general-purpose parser that can take any WeBWorK problem, PG or PGML style, and extract from it the types of questions in the problem and all of the data necessary to load the supported question types into GUIWorK? If so, I think that this might be a huge undertaking and that we should talk about this.

[SchmidtNikolas]

Currently trying an approach to rewrite with ES6 modules, hence the new branch. I'll have to make a bit more progress before I get around to providing more details on this, I just wanted to push something upstream to have a backup in case of the apocalypse. (Or another one, depending on your classification of current events.)