Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Isaiah Mayerchak
    @flysaiah
    Also--we fixed the safari problem; apparently Safari doesn't support drag-n-drop with any elements that are display:inline-block, so we had to modify our css rules to change our divs to inline with a float:left attribute. It works in Chrome, Firefox and Safari now.
    Bradley Miller
    @bnmnetp
    good work
    Kirby Olson
    @riknos314
    As we keep making more components have parts that depend on other components, such as allowing clickable area and drag n drop in timed assessments, it is getting harder and harder for us to figure out how to get sphinx to place the javascript files in an order that satisfies all of the dependencies created. Would it be possible for you to come in tomorrow so we can work on figuring out a method of resolving these dependencies as we move forward?
    Bradley Miller
    @bnmnetp
    We can do a hangout and brainstorm about this tomorrow. But, I have been thinking about this problem in the back of my mind. And I want to say that the real solution is to make the components smart enough that the order of the js files does not matter.
    Kirby Olson
    @riknos314
    I believe that currently they are order agnostic with the exception of needing the file with the constructor method of the component to come before any file that calls that constructor method.
    I'm not sure how we'd get around this because you can instantiate a prototype that hasn't yet been defined.
    *can't
    Isaiah Mayerchak
    @flysaiah
    One solution that we just tested is we added a new directory in RunestoneComponents that just has an init.py that adds all of our custom javascript files in the order we want. The other init.py files of each respective component still add their directives/css/etc, but we moved all of the addjavascript calls to our masterJS _init.py----it's a little hacky, but it solves all of our JS order problems for now and the future as well. What do you think of this?
    add_javascript*
    Bradley Miller
    @bnmnetp
    The constructor issue should not be a problem because all of the javascript files will be loaded before the document.ready event happens.
    putting all of the javascript into a separate __init__.py file is an OK solution if we really need to control the ordering. It kind of breaks the modularity of each component, but I guess in some cases that might be unavoidable as ultimately they work together and are interdependent.
    Kirby Olson
    @riknos314
    The ordering problem comes when one prototype expands upon another prototype, the prototype that is being expanded upon must be defined before the prototype that is expanding upon it.
    Kirby Olson
    @riknos314
    For instance, in the new timed implementation we have a class called timedMC which contains the timed-specific methods for the MC prototype. The timedMC prototype inherits the prototype of the MC class, then adds/overwrites some methods to make it work in a timed assessment. Since timedMC has line timedMC.prototype = new MultipleChoice(); as part of the declaration of the prototype (outside of a document.ready event), the file containing the MultipleChoice prototype must come before the file with the timedMC prototype.
    Isaiah Mayerchak
    @flysaiah
    We just found a better solution that doesn't require the master-js-adding python file, so the modularity of each component will still be preserved.
    Bradley Miller
    @bnmnetp
    Had some feedback from Barb on the clickableArea directive. She would also like to be able to provide an image or images and have them select. Or give a 2D array and have them click in the proper cell.
    Any thoughts? Would an clicking on an image be a separate component? Could we make the container a div instead of a pre so that any arbitrary html like an image or td could be clickable?
    Isaiah Mayerchak
    @flysaiah
    It's possible that we could implement stuff like tables into the current component, but doing a clickable image where someone can click different parts of an image is most likely going to have to be in a different component, just because all of the methods for processing it/evaluating it are going to be completely different. We need some time to think it through, though.
    Unless she's thinking of choosing between multiple images, and only being able to click an image as a whole (instead of different parts of the same image)--that would probably be doable in our current component with minimal tweaking.
    Bradley Miller
    @bnmnetp
    So, if we can put things (including images) into a table and pick from the table then Barb is probably happy. — so we can avoid picking parts of the same image.
    Isaiah Mayerchak
    @flysaiah
    Ok. I think that can still work with the current component--I'll probably add a data-table option that will allow for that functionality.
    (In the intermediate HTML)
    Isaiah Mayerchak
    @flysaiah
    So, am I right in thinking that what we're doing now is making an option that allows the author to create a table and designate certain table cells as being clickable?
    Bradley Miller
    @bnmnetp
    That is one way to approach it. The other way would be to make the clickablearea component flexible enough that it is a container, and any embedded html element could be clickable.
    Isaiah Mayerchak
    @flysaiah
    We'll do the second approach--that sounds much better.
    Bradley Miller
    @bnmnetp
    @riknos314 I see what you mean now about webpack and its namespace limitations. I think this is a big problem for us as we can’t control what other .js files people may use on their website.
    Kirby Olson
    @riknos314
    It is unfortunate. I haven't looked into whether or not using the AMD style modules has the same namespacing as the commonJS conventions, but I'm not hopeful.
    Bradley Miller
    @bnmnetp
    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. ?
    Kirby Olson
    @riknos314
    I'll see if I can find anything
    Bradley Miller
    @bnmnetp
    For the skulpt project we use the google closure compiler to package together a bunch of individual .js files into skulpt.min.js
    Kirby Olson
    @riknos314
    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.
    Bradley Miller
    @bnmnetp
    Yes, and I know that it does preserve ordering as that is important for some things in skulpt as well.
    Kirby Olson
    @riknos314
    Excellent, I'll play around with that a bit today and try to get it running.
    Bradley Miller
    @bnmnetp
    Great. Thanks.
    Make sure you update your branch as I have been busy pushing changes to master.
    Isaiah Mayerchak
    @flysaiah
    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.
    Bradley Miller
    @bnmnetp
    Yes, there are directives for adding an image and there is a syntax for making a table in rst. google sphinx restructuredtext primer
    Bradley Miller
    @bnmnetp
    @flysaiah, hint: This is where the nested_parse call becomes very important.
    Isaiah Mayerchak
    @flysaiah
    The problem I'm envisioning is if someone creates an img tag via Sphinx, we need to edit that img tag so that it has the attribute data-correct or data-incorrect. Wouldn't the nested_parse call just create the img tag without letting us change some of its properties?
    Bradley Miller
    @bnmnetp
    The details are very hazy, but I think once you have a node you can get access to its children.
    Isaiah Mayerchak
    @flysaiah
    Ok. I'll tinker around with it and see what I can do.
    Bradley Miller
    @bnmnetp
    Or you could create a role like the textarea role that you would use to surround an element that you want to be clickable kind of like what you are doing now, but more tricky, rather than adding an attribute. So I think you have two ways to go.
    Isaiah Mayerchak
    @flysaiah
    So, with the first way, are you suggesting that somewhere during the nested_parse process we could grab all of the nodes that it is parsing and modify them?
    Bradley Miller
    @bnmnetp
    I think that would happen during the visit_xxxx_node call not during parsing.
    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.
    Isaiah Mayerchak
    @flysaiah
    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.
    Bradley Miller
    @bnmnetp
    The css can be adjusted to not apply to images.