PG Text post processing #897
Conversation
drgrice1
force-pushed
the
post-process-text
branch
22 times, most recently
from
2cd5384 to
dff345a
Compare
drgrice1
force-pushed
the
post-process-text
branch
from
dff345a to
6b0596c
Compare
|
Saw that you updated with the scaffolding. Just played with one problem and there's an extra (unstyled) preview button: |
|
That doesn't exactly make sense. The submit buttons are not added by PG at all. They are added by webwork2 after PG finishes rendering the problem. |
|
@pstaabp: I am guessing that you have something else going on unrelated to this pull request. Perhaps you need to run |
|
You're right. It was doing this in develop and it was a problem with my custom theme--I had another issue with the fact that some of the files were copies and not links to the math4/ versions. All fixed now. |
drgrice1
force-pushed
the
post-process-text
branch
from
6b0596c to
151e686
Compare
drgrice1
force-pushed
the
post-process-text
branch
from
151e686 to
cd5e7c9
Compare
drgrice1
force-pushed
the
post-process-text
branch
14 times, most recently
from
3ed91df to
299e247
Compare
drgrice1
force-pushed
the
post-process-text
branch
3 times, most recently
from
dce4d1c to
1219e56
Compare
drgrice1
force-pushed
the
post-process-text
branch
2 times, most recently
from
e6349e3 to
cdf779d
Compare
drgrice1
force-pushed
the
post-process-text
branch
2 times, most recently
from
6896524 to
16a8622
Compare
Macros or problems can add a hook by calling `add_content_post_processor` with a subroutine that will be called after the translator has processed answers. For all display modes except TeX, the subroutine will be passed the problem text parsed into a Mojo::DOM object and a reference to the header text. For the TeX display mode a reference to the problem text is passed. The subroutine can then modify the problem DOM or text, and header text. The resulting Mojo::DOM object will be converted back to a string and the problem text reference returned by the translator set to point to that string. Note that the `$PG_PROBLEM_TEXT_ARRAY_REF` has been removed from the translator code. It is never used and is redundant with the `$PG_PROBLEM_TEXT_REF` which is all that is used. It was becoming annoying to maintain both in a compatible manner. The hidden MathQuill inputs for the latex string is added in this post processing stage (see the ENDDOCUMENT method in PG.pl).
This means that answers are no longer evaluated by the macro. Instead the scaffold sections are finalized after the answers are processed normally by the translator.
This is so that the content post processor methods have access to the full answer objects. This gives this approach a whole lot more power than the (soon to be eliminated) results table has.
drgrice1
force-pushed
the
post-process-text
branch
from
16a8622 to
c01a16b
Compare
|
Probably all is well now, but there is an extra button like the preview button here that is usually hidden. It is the button that is "clicked" if you hit enter from an input field. You can configure so that button might be check/submit instead. I'm guessing this is the button you saw. |
Macros or problems can add a hook by calling
add_content_post_processorwith a subroutine that will be called after the translator has processed answers. For all display modes except TeX, the subroutine will be passed the problem text parsed into a Mojo::DOM object and a reference to the header text. For the TeX display mode a reference to the problem text is passed. The subroutine can then modify the problem DOM or text, and header text. The resulting Mojo::DOM object will be converted back to a string and the problem text reference returned by the translator set to point to that string.The hidden MathQuill inputs for the latex string is added in this post processing stage (see the ENDDOCUMENT method in PG.pl).
The scaffold.pl macro is updated to use this post processing. This means that answers are no longer evaluated by the macro. Instead the scaffold sections are finalized after the answers are processed normally by the translator.