Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rework the persistence hash and add new scaffold preview option. #1165

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from

Conversation

drgrice1
Copy link
Member

@drgrice1 drgrice1 commented Dec 17, 2024

This replaces all of the previous persistence hash methods with a single peristent_data method. This method both saves to and retrieves from the persistence hash. The first (or second including self in PGcore) parameter is the key in the persistence hash. If the optional second (or third including self in PGcore) parameter is not given then the value of the key for the given label in the hash will be returned. If the second parameter is given then the value of the key in the hash will be saved or updated. Note that if third parameter is given but is undefined then the key will be deleted from the hash. Anything that can be JSON encoded can be stored.

Any front end should save the persistence hash in some way, and send it back each time the problem is rendered. Although the front end reserves the right not to save this if it deems that this is a case that data should not be persistent.

The store_persistent_data, update_persistent_data, and get_peristent_data methods from before still exist in PG.pl (but were removed from PGcore.pl) and they all just call the new persistent_data method. However, they should be considered deprecated, and are only left for backwards compatability. Note that the store_persistent_data method no longer warns if one tries to set the data for a key in the hash that is already set. There was no reason for that warning and probably is why the update_persistent_data method was created that does exactly the same thing except that it doesn't warn and it doesn't return the label that was passed in (why do that anyway?). The whole mechanism was rather poorly designed to begin with.

Add a scaffold preview_can_change_state option that determines behavior when preview is used. The default value is 1, and in that case scaffolds will continue to behave as they currently do. If this option is set to 0, then when an answer preview occurs, the scaffold state will remain the same as before the preview occured. Opened scaffolds will stay open, closed scaffolds will stay closed, and scaffolds that could't be opened still can't be opened. Note this refers to the initial open/closed state when the problem loads, and does not respect opening or closing of scaffolds (that can be opened or closed) by the user.

This uses the persistence hash to store the state. Note that state is really the scores for all answers in scaffold sections. It is important to note that state is usually not saved by the frontend until an answer submission occurs (although it is saved in a hidden form field for instructors), and if there is no state, then it assumes the problem is in its initial state, and uses scores of 0 for all answers.

Note that this replaces #506.

This replaces all of the previous persistence hash methods with a single
`peristent_data` method.  This method both saves to and retrieves from
the persistence hash.  The first (or second including self in PGcore)
parameter is the key in the persistence hash.  If the optional second
(or third including self in PGcore) parameter is not given then the
value of the key for the given label in the hash will be returned.  If
the second parameter is given then the value of the key in the hash will
be saved or updated.  Note that if third parameter is given but is
undefined then the key will be deleted from the hash.  Anything that can
be JSON encoded can be stored.

Any frontend should save the persistence hash in some way, and send it
back each time the problem is rendered.

The `store_persistent_data`, `update_persistent_data`, and
`get_peristent_data` methods from before still exist in PG.pl (but were
removed from PGcore.pl) and they all just call the new `persistent_data`
method.  However, they should be considered deprecated, and are only
left for backwards compatability.  Note that the `store_persistent_data`
method no longer warns if one tries to set the data for a key in the
hash that is already set.  There was no reason for that warning and
probably is why the `update_persistent_data` method was created that
does exactly the same thing except that it doesn't warn and it doesn't
return the label that was passed in (why do that anyway?). The whole
mechanism was rather poorly designed to begin with.
…vior when preview is used.

The default value is 1, and in that case scaffolds will continue to
behave as they currently do.  If this option is set to 0, then when an
answer preview occurs, the scaffold state will remain the same as before
the preview occured.  Opened scaffolds will stay open, closed scaffolds
will stay closed, and scaffolds that could't be opened still can't be
opened.  Note this refers to the initial open/closed state when the
problem loads, and does not respect opening or closing of scaffolds
(that can be opened or closed) by the user.

This uses the persistence hash to store the state. Note that state is
really the scores for all answers in scaffold sections.  It is important
to note that state is usually not saved by the frontend until an answer
submission occurs (although it is saved in a hidden form field for
instructors), and if there is no state, then it assumes the problem is
in its initial state, and uses scores of 0 for all answers.
@drgrice1 drgrice1 force-pushed the persistent-data-rework branch from cb566bb to 788f8d1 Compare December 18, 2024 14:23
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