Dynamic population of blocks and flyout

[tmickel]

I think the capability to do this is mostly already available, but we should maybe think about how it should be generally approached.

I suspect we would like to structure our applications using scratch-blockly such that we can define and inject blocks outside the main Blockly package. For example, we will have Scratch extensions that can define arbitrary blocks. One approach for dealing with this could be injecting new blocks into Blockly.Blocks on runtime. This seems to be how blocks/* works anyway, but I would like to confirm that this makes sense and won't break any assumptions Blockly may be making.

I also suspect we would like to choose what is populated in the flyout in a format that is not a fixed XML tree. For example, when users will add extensions that have new blocks, we'd like to dynamically feed the flyout the list of injected blocks to display. I believe we could generate a mini XML tree on the fly, and then feed it to workspace.toolbox_.flyout_.show, but would also like to confirm that this makes sense or if we should implement some special functionality.

@thisandagain @rachel-fenichel @NeilFraser

[rachel-fenichel]

Take a look at flyout.js to see how dynamic population of the flyout can be
done https://github.com/LLK/scratch-blockly/blob/develop/core/flyout.js#L538

On Fri, Mar 11, 2016 at 11:05 AM Tim Mickel notifications@github.com
wrote:

I think the capability to do this is mostly already available, but we
should maybe think about how it should be generally approached.

I suspect we would like to structure our applications using
scratch-blockly such that we can define and inject blocks outside the main
Blockly package. For example, we will have Scratch extensions that can
define arbitrary blocks. One approach for dealing with this could be
injecting new blocks into Blockly.Blocks on runtime. This seems to be how
blocks/* works anyway, but I would like to confirm that this makes sense
and won't break any assumptions Blockly may be making.

I also suspect we would like to choose what is populated in the flyout in
a format that is not a fixed XML tree. For example, when users will add
extensions that have new blocks, we'd like to dynamically feed the flyout
the list of injected blocks to display. I believe we could generate a mini
XML tree on the fly, and then feed it to workspace.toolbox_.flyout_.show,
but would also like to confirm that this makes sense or if we should
implement some special functionality.

@thisandagain https://github.com/thisandagain @rachel-fenichel
https://github.com/rachel-fenichel @NeilFraser
https://github.com/NeilFraser

—
Reply to this email directly or view it on GitHub
#119.

[thisandagain]

Depends on #21

[tmickel]

Better described in #682.