Packaging of the Runestone tools for publishing educational materials using github pages
For the second, The idea is that during visit_xxx_node you can create the opening tag. and then during depart_xxx_node you create the closing tag
You might experiment by printing self.body in both the visit and the depart to see what you have available there too.
Yes--the second way I think I understand, it would pretty much be what I'm doing now, which is wrapping the clickable element in a span, but that would be a problem when it comes to images because of my CSS rules. I think the first way would probably be cleaner, too, it's just I'm not sure how exactly I'd do it. I'll do those print statements.
@bnmnetp I'm getting some strange behavior out of self.state.nested_parse() when the directive has content that isn't composed solely out of other directives (i.e. text). The content is getting parsed twice--for example, in the RST
.. clickablearea:: click1
:question: Click on all assignment statements.
:feedback: Remember, the operator '=' is used for assignment.
:click-incorrect:def main()::endclick:
:click-correct:x = 4:endclick:
for i in range(5):
:click-correct:y = i:endclick:
:click-incorrect:if y > 2::endclick:
print(y), the code block starting with :click-incorrect: is getting rendered once normally, then once again after the full component has been rendered like this:
<dl class="docutils">
<dt>:click-incorrect:def main()::endclick:</dt>
<dd><p class="first">:click-correct:x = 4:endclick:
for i in range(5):</p>
<blockquote class="last">
<div><p>:click-correct:y = i:endclick:
:click-incorrect:if y > 2::endclick:</p>
<blockquote>
<div>print(y)</div></blockquote>
</div></blockquote>
</dd>
</dl>Do you know why this is happening? It's a big roadblock and I'm unsure of what to do about it.
Trying to combine the javascript files with google closure compiler hasn't been very fruitful. After modifying many of the files (getting rid of trailing commas) to stop the linter from throwing errors so that I could actually compile, the file that I get back doesn't work. I tried setting the compiler to the 'whitespace_only' setting so that it wouldn't minify variable names, and that still doesn't work. It appears to cause the various versions of jquery that we have to not play well with each other as I'm continually running into errors with
$(...).method() is not a function where method is any number of different methods. I'll try a couple other methods and see if anything works.
I guess that I could experiment with making a few, smaller bundles. I just really don't want to mess with the order that things are loaded in because that has proven to be quite fragile in my experience.
I just tried concatenating the files at your suggestion, and I'm getting the exact same problems. Just to be sure that I didn't mess up the concatenation I grepped through the combined file and the methods are indeed defined. Maybe the files are parsed differently as individual files? I'll do some research.
I'm running into problem after problem with trying to wrap things inside click-correct or click-incorrect elements in rST for clickablearea, and I'm becoming increasingly doubtful about the possibility of it working at all, so I came up with another solution. In the case of having a number of images or a table, in the option spec of clickablearea the user can specify the indices of the images they would like to be correct, and the indices of the images they would like to be incorrect--much like what we do with multiple choice multiple answer. For example, if the user has 5 images inside the clickablearea directive they can list images 2, 3, and 5 as being correct and 1,4 as being incorrect. In a table, each data cell would be one index. If all they have is text, they can specify that with :iscode: and still wrap whatever they want in click-correct and click-incorrect wrappers--the index method will only be for images/tables/etc, so the old functionality is still preserved. The only limitation this has is that people won't be able to make both images and plain text (that isn't in a table) clickable in the same element (they can't use both indices AND wrappers), but I don't think that's something that would be very popular to do in the first place. Does this sound reasonable?
In the old case, everything would work as it has, so yes. In the new images/table case, the html wouldn't have the data-correct or data-incorrect attribute but I can add a data-correctElements and data-incorrectElements to the clickablearea component and add a function in our javascript that will parse those and the rest of the component will behave the same.
It will be a feature that's really only for the Sphinx-rST parsing, but I've been running into a brick wall with doing this in Sphinx whereas I know this will work in the JS.
If you could take a look at them and get some fixes. It would be nice to have one PR per fix unless they are really trivial, then I don’t mind if you bundle them.
I think we're seeing different errors with Parsons. I just checked the page source of the overview page on the example that's not working for me and it has all of the code it should have, it's just not rendering.
<pre data-component="parsons" id="question1_100_4">
<span data-question>sc-1-3: Construct a block of code that correctly implements the accumulator pattern.</span>x = 0
for i in range(10)
x = x + 1</pre>
I found the source of the problem--it's very strange, but after lots of console.logs I found that on line 870 of parsonsaux.js (which is where parsons errors out when runestonebase is on the page), the value of permutation[i] is an integer for the first 3 passes in the for loop, and the 4th pass through its value is
"function Array.includes(searchElement)" which is declared in runestonebase. I have no idea how that is getting into the permutation array, but that's what's happening.
"function Array.includes(searchElement)" which is declared in runestonebase. I have no idea how that is getting into the permutation array, but that's what's happening.
The array only has 3 elements, but I think because whoever wrote the code for the function is doing iteration by items instead of by position, it is somehow accessing the prototype function of Array as an item in the array.
I was right: I changed all of the iterations by item to iterations by position (i.e. instead of "for var i in array_" it's now "for (var i = 0; i < _array.length; i++) and parsons is no longer broken. I'm fairly certain the same thing is happening in codelens, which is what is causing it to break too. I'll do a PR on this and on CL too when I fix too.
In the meantime, I am removing that polyfill implementation of includes. I don’t know why I didn’t just write
if (x in [‘java’, ‘cpp’…]) in the first place.
I'm struggling a bit with figuring out why the multi-line isn't working. The Sphinx side is actually working pretty well--most of the code that I deleted from the old parsons.py is functionality that needed to be implemented in the JS, because it was turning multiple line code into single line code with a "\n" replacing the actual newline character, which I should be able to do easily in the JS side. However, even when I hardcode some code in the JS side from an actual working example from the site--for example:
import turtle\nwindow = turtle.Screen()\nella = turtle.Turtle()This should render one draggable parsons element that is multiple lines of code, but when I hardcode it and pass it into the ParsonsWidget object, it actually still renders as one draggable element, but it is one really long line with actual spaces instead of newlines. Also, I realized that in working examples of Parsons on interactivepython.org, all of the draggable code on the parsons problems have their text wrapped in a multitude of <span> elements. It looks like this happens in prettify.js, and we're including it in our test pages, but none of our code is being wrapped in those spans. I'm wondering if these two things are related.
In some other components I know that others have resorted to using nl or some other string to indicate a newline as escaping this stuff can be tricky.
Unfortunately, even manually entering <br /> tags into the HTML code isn't creating newlines in the parsons objects--in the <parsons-orig-divid> div, which is where the original code is stored, the <br> tag is definitely present, but it's not doing anything to the element on screen--the <br> is not appearing inside the unordered list that contains each draggable element. The ParsonsWidget should just be grabbing whatever is in that parsons-orig div and turning it into the right element, but I'm not sure what's going wrong. I'll mess around with it some more.
I fixed it! It had to do with the jquery method we were using to pass the original HTML text into the Parsons Widget. Before we were using $(this.origDiv).text() instead of $(this.origDiv).html() to get what we needed, which has been giving us problems in other components too. I have to bring my brother to his tennis event, but will finalize the fix and do a pull request in a few hours.