Composite Blocks in Blockly

[Abhigya jain]

Hi Team,

I have been using Blockly extensively for my current project and most of the times that i build my workflows using Blockly blocks , the number of blocks exceed 1000 and even more. Viewing such large workflows becomes a problem.

I want to be able to have a 'Composite' block functionality - wherein - say, i have a composite block and i drag and drop 5 atomic blocks inside it, and all that i can see on the screen then is that 1 composite block instead of those 5 blocks.

e.g. i have block A, block B, block C, block D and block E on the blockly workspace. If i create a custom block , which is a composite block (Block CB ) and drag and drop these 5 blocks inside it, then visually on the screen what is left if just this Block CB. Internally though in the Blockly XML, it holds the block definition of all the blocks it contains.

It something like this possible with Blockly? Could you Guide me how i could start with it ? 

Regards

Abhigya

[Neil Fraser]

Have you considered making a container block (basically a "repeat 1 times {...}" block), then collapsing it?

--
You received this message because you are subscribed to the Google Groups "Blockly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blockly+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Neil Fraser
https://neil.fraser.name

[Abhigya jain]

Actually the "expand block" and "collapse block" functionality is just a cosmetic change on the screen. the moment i'll say expand block, all those 5 blocks within that 1 container block would still show on the page.

What i am looking for is a way of "Blocks Abstraction". Say if i could abstract 5 logically sequential blocks into 1 Abstract block 

so say if my workflow has 2000 blocks , but each set of 100 blocks in this workflow are a logical unit of blocks. I want to be able to put each of these 100 blocks into their own composite block . That ways i now have only 20 Blocks on my screen + i can know by the composite block name itself what the block does. Thus hiding all those 100 blocks behind it. 

The atomic blocks though would be held in the xml since that information would be needed at the time of replaying the code.

[Andrew n marshall]

For user defined behaviors, function blocks are the abstraction you are looking for.

That said, you appear to want to push the function definitions to another workspace, which is a reasonable request. The obvious challenge here is defining a way to switch between workspaces. I think there are so many possible solutions to this, we would be hesitant to provide a specific solution too early, without a lot of community feedback and user testing. Structuring the multiple workspaces around functions and function definitions is just one possible approach, and I'm certain there are numerous other use cases that would have different needs.

The bigger issue is coordinating multiple workspaces as a single project.

The easy part is composing the workspaces into one workspace for code generation; appendDomToWorkspace() should help with that.

A harder problem is storing these multiple workspaces as a single entity, for saving and loading. Our current XML assumes a single workspace.

And still harder is coordinating all the variables and functions across the multiple workspaces, so that variable renames, function renames, argument list changes all update correctly across all workspaces. This may involve loading hidden workspaces in a headless mode so they are available for inspection and updates without the SVG overhead.

Some of these issues have been discussed within the team, but they are not on the current roadmap.  I think we would be open to accepting an experimental demo that iteratively attempts to explore these issues, giving everyone a test platform for the new APIs required to support the target features.

Let us know if you'd like to work on these project.  We'd be happy to give you some guidance to help ensure its success and possible adoption.