You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@pmitros: "It'd be nice if I could pass parameters to frag.initialize_js. I'd suggest these could be JSON objects (so string, dicts, arrays, integers), and I could have anywhere between 0 and infinity of them.
Right now my options for doing this are:
Add templates to my HTML/JS/CSS. This is ugly.
a. I can no longer develop in browser without running the workbench. It forces my code to couple to workbench. I know I could probably find some way to split this among files where there is a test file and a workbench file, but that kind of sucks.
b. It forces me to put things inside HTML/CSS/JS files that break the semantics of what those files mean. I have to template in big data blobs in human-readable files.
I can do AJAX, with extra requests.
In addition, in both cases, it's an extra chunk of unnecessary code. I have to do $("#script_tag").text() or make web requests or similar."
@cpennington: "How does it couple you to workbench? Unlike XModules, w/ XBlocks we're advocating that users do their own templating (rather than relying on the runtime for templating). For instance, you could just do native python string interpolation, if that's enough for your needs.
Otherwise, I like the idea."
@pmitros: "If I can keep pure JavaScript, HTML, and CSS in files, I can develop and debug directly in Chrome/Firefox, as per my preference, and I can deploy either to the XBlock, or just upload static files to the web.
The instance I have /any/ kind of templates, be it Python .replace(), Python .format(), mako, etc., the code can only work inside of some kind of server which does that templating. I'm coupled to a more complex development and deployment mechanism. In abstract, I could build a separate server, one for XBlocks and one not to do the templating, or build an independent deployment mechanism, but in practice, that's a lot of work with no benefit (if I need a server, workbench is as good as any and better than most), so I'm left with developing in workbench. Being able to develop and deploy just in-browser is, on the other hand, a big benefit, as is being able to use the same HTML/CSS/JS files for both interactives on static pages as in XBlocks."
The text was updated successfully, but these errors were encountered:
@pmitros: "It'd be nice if I could pass parameters to frag.initialize_js. I'd suggest these could be JSON objects (so string, dicts, arrays, integers), and I could have anywhere between 0 and infinity of them.
Right now my options for doing this are:
a. I can no longer develop in browser without running the workbench. It forces my code to couple to workbench. I know I could probably find some way to split this among files where there is a test file and a workbench file, but that kind of sucks.
b. It forces me to put things inside HTML/CSS/JS files that break the semantics of what those files mean. I have to template in big data blobs in human-readable files.
In addition, in both cases, it's an extra chunk of unnecessary code. I have to do $("#script_tag").text() or make web requests or similar."
@cpennington: "How does it couple you to workbench? Unlike XModules, w/ XBlocks we're advocating that users do their own templating (rather than relying on the runtime for templating). For instance, you could just do native python string interpolation, if that's enough for your needs.
Otherwise, I like the idea."
@pmitros: "If I can keep pure JavaScript, HTML, and CSS in files, I can develop and debug directly in Chrome/Firefox, as per my preference, and I can deploy either to the XBlock, or just upload static files to the web.
The instance I have /any/ kind of templates, be it Python .replace(), Python .format(), mako, etc., the code can only work inside of some kind of server which does that templating. I'm coupled to a more complex development and deployment mechanism. In abstract, I could build a separate server, one for XBlocks and one not to do the templating, or build an independent deployment mechanism, but in practice, that's a lot of work with no benefit (if I need a server, workbench is as good as any and better than most), so I'm left with developing in workbench. Being able to develop and deploy just in-browser is, on the other hand, a big benefit, as is being able to use the same HTML/CSS/JS files for both interactives on static pages as in XBlocks."
The text was updated successfully, but these errors were encountered: