Switch applets from storing state via RECORD_FORM_LABEL to using the PERSISTENCE_HASH.
#1353
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
drgrice1
force-pushed
the
geogebra-applet-update
branch
from
6e5d210 to
80fea8f
Compare
drgrice1
force-pushed
the
geogebra-applet-update
branch
from
80fea8f to
6c1289a
Compare
pstaabp
approved these changes
Dec 30, 2025
Member
pstaabp
left a comment
pstaabp
left a comment
There was a problem hiding this comment.
Couldn't get the correct answer with the given problem, but the problem state is now saving with this PR.
pstaabp
reviewed
Dec 30, 2025
macros/graph/AppletObjects.pl
Outdated
| type => 'button', | ||
| class => 'btn btn-primary applet-reset-btn mt-3', | ||
| 'data-applet-name' => $appletName, | ||
| 'Return this question to its initial state' |
Member
There was a problem hiding this comment.
I noticed that since the problem you provided was in French and the restore state button was in English, that we could wrap this line in a maketext.
Member
Author
There was a problem hiding this comment.
I added the maketext call here.
drgrice1
force-pushed
the
geogebra-applet-update
branch
from
6c1289a to
9286e5a
Compare
drgrice1
force-pushed
the
geogebra-applet-update
branch
from
9286e5a to
bed0143
Compare
…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.
drgrice1
force-pushed
the
geogebra-applet-update
branch
from
bed0143 to
114272f
Compare
…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.
drgrice1
force-pushed
the
geogebra-applet-update
branch
from
114272f to
1374218
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The applet state is not a "kept extra answer" which is what the
RECORD_FORM_LABELapproach is for. The applet state isn't an answer at all. It is just extra problem data that needs to persist. So exactly what thePERSISTENCE_HASHis for. In addition, webwork2 stores the kept extra answers in thelast_answercolumn which is typeTEXTand thus limited to 64KB. The data in thePERSISTENCE_HASHis stored in theproblem_datacolumn which is of typeMEDIUMTEXTand 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
insertAllmethod of theAppletObjects.plmacro. It can take advantage of thetagmethod.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
preventDefaulton 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_answercolumn.LogScale.pg.txt