Skip to content

Conversation

@drgrice1
Copy link
Member

@drgrice1 drgrice1 commented Dec 5, 2025

The applet state is not a "kept extra answer" which is what the RECORD_FORM_LABEL approach is for. The applet state isn't an answer at all. It is just extra problem data that needs to persist. So exactly what the PERSISTENCE_HASH is for. In addition, webwork2 stores the kept extra answers in the last_answer column which is type TEXT and thus limited to 64KB. The data in the PERSISTENCE_HASH is stored in the problem_data column which is of type MEDIUMTEXT and so can hold up to 16MB of data. The applet state can become larger than 64KB as is evidenced by the issue posted in the forums at https://forums.openwebwork.org/mod/forum/discuss.php?d=8785.

This also removes a FIXME that has been in the code since 2010 that states that this should be done.

There is also a litle clean up of the insertAll method of the AppletObjects.pl macro. It can take advantage of the tag method.

Finally, switch ww_applet_support.js from using a submit handler to click handlers on the submit buttons. This makes applet problems work in the PG problem editor of webwork2. The PG problem editor uses click handlers on the submit buttons as well, but calls preventDefault on the event, and prevents the form submission from occuring. That prevents the current submit handler set in the ww_applet_support.js code from happening. Thus the answers for applets do not get submitted. By using the click handlers this gets in at the same point that the PG problem editor handlers are, and they still occur. All click handlers are executed even if one of them prevents default behavior.

Note that to work correctly with problem randomization or with show me another problems, this depends on openwebwork/webwork2#2855.

The attached problem can be used to test this. That problem will not even work without this pull request because the state is to large for the last_answer column.

LogScale.pg.txt

…e `PERSISTENCE_HASH`.

The applet state is not a "kept extra answer" which is what the
`RECORD_FORM_LABEL` approach is for.  The applet state isn't an answer
at all.  It is just extra problem data that needs to persist.  So
exactly what the `PERSISTENCE_HASH` is for.  In addition, webwork2
stores the kept extra answers in the `last_answer` column which is type
`TEXT` and thus limited to 64KB.  The data in the `PERSISTENCE_HASH` is
stored in the `problem_data` column which is of type `MEDIUMTEXT` and so
can hold up to 16MB of data.  The applet state can become larger than
64KB as is evidenced by the issue posted in the forums at
https://forums.openwebwork.org/mod/forum/discuss.php?d=8785.

There is also a litle clean up of the `insertAll` method of the
`AppletObjects.pl` macro.  It can take advantage of the `tag` method.
…lers on the submit buttons.

This makes applet problems work in the PG problem editor of webwork2.
The PG problem editor uses click handlers on the submit buttons as well,
but calls `preventDefault` on the event, and prevents the form
submission from occuring.  That prevents the current submit handler set
in the ww_applet_support.js code from happening.  Thus the answers for
applets do not get submitted.  By using the click handlers this gets in
at the same point that the PG problem editor handlers are, and they
still occur.  All click handlers are executed even if one of them
prevents default behavior.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant