Packaging of the Runestone tools for publishing educational materials using github pages
(In the intermediate HTML)
On the other hand, to make it easy for people to use the components outside of Sphinx, We really should bundle them up as one minified whole. Can you check into a couple of other options. Even if it is just a script to package them up together into a single runestone.js file. ?
I basically automates the google closure compiler process
I see no reason why we couldn't also use the google closure compiler as long as it maintains order so we can keep our prototype definitions working.
Make sure you update your branch as I have been busy pushing changes to master.
We've modified clickable area so that it's a container that can hold anything, and anything within that container that has the data-correct or data-incorrect attribute will be clickable. This works perfectly with our intermediate HTML, but I'm not quite sure how to proceed with the Sphinx side. Are there ways that people can create tables/images/etc. in RST right now? Everything I've been working with up to this point has been with RST users entering just simple text (for questions/feedback/etc), but I'm not sure how to give them the freedom to put whatever they want into a clickable area container (ex. image or table) if there's no pre-defined way to do that.
Right now the only way we can think of to give people that freedom is to have them write a block of HTML code and put it in a string in the RST.
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.