...
We use “blocks” in the API a lot, but some things should be generically applicable to components (e.g. file upload, tagging), some are applicable to any publishable thing (e.g. “publish”), and some are specific to XBlocks.
XBlock Compilation Step?
We currently parse block.xml for our field data parsing, but in the past we’ve talked about having a compilation step so that we could do things like:
pre-render math into MathML on the server side
store Python source files next to the
block.xmland compile them in.store HTML data in an HTML file, rather than in CDATA
The goal would be to give better authoring flexibility while making sure that any content data that an XBlock needs is entirely contained within one row of a model that is 1:1 with ComponentVersion. This might only work well once we have courses switched over to use Learning Core.
Extensibility
We should work as much of our own code into Slots and other extension points–at least as much as is practical.
I think Sumac is our “sure, kick the tires, but don’t actually extend this” release, and we should target Teak for our first actually usable extension points for enhancing the content libraries experience.
...