Enhancement: Mutator within block definition

[GoogleCodeExporter]

Dear all,

within my project I need to create blocks on the workspace on user actions (the 
user does not drag&drop the block to the workspace, but clicks e.g. on a 
checkbox and new blocks are visualized). Standard blocks can be handled easily 
and I can see all required names, parameters, etc. in the xml representation of 
the block (e.g. block type, statement/value input area name, etc.), so that 
these can also be easily changed. For mutator enabled blocks not all 
information are visible within the xml representation or on the block itself, 
so that the block definition has to be opened to get the variable names and 
number of the active mutator elements (itemCount_, elseifCount_, elseCount_, 
etc.). 

Wouldn't it be more beneficial to have the count within the mutator object?
When we create a new mutator we specify statement blocks visible in the mutator 
bubble (mutator workspace). We could use the length of this list to create a 
new count list within the mutator object, which holds the numbers each element 
respectively.

Also possible would be to provide a list of element objects within the mutator 
object. Stored can be: 
The name of the block definition
The number of elements in use
The name within the mutator xml child
Additional information, ...

Why would it help to make the mutator easier?
The main advantage is, that we do not need to know, or even specify the 
...Count_ names, but just use mutator.listName[0] to get access to the first 
elements. The domtoMutation and mutationToDom functions wouldn't need to know 
the  ...Count_ names at all and could use the list instead. 

Each change of a ...Count_ variable name requires the change of the name at 
several places (maybe cumbersome). This renaming wouldn't be necessary. As long 
as we know which element is at which position in the list we can handle them 
properly. 

Additionally, a newly created block can be mutated without knowing the variable 
names and the number of available elements (they can be found by using 
mutator.listName.length, etc.) 

Even the value can change, so that for if, list, and other blocks a number can 
be added and for the procedures a list. 

As far as I can see there won't arise other problems. At least none which not 
already exist. E.g. creating a mutator enabled block with less elements than by 
standard available lead to artefacts. In order to prevent the artefacts the 
block has to be transformed to dom(xml) representation, the element numbers 
have to be changed and then transformed back to block representation, ...

Conclusion: Having the mutator specific variables within the mutator object 
would separate the mutator features (except of the creation of the object 
itself) from the block init function. The mutationToDom and domToMutation 
function do not need to know block variables but can use the element list to 
get/set all required parameters/values/etc.

Even the creation of a mutator enabled block by a right click option or by any 
other means would be simplified, because once again only the list elements have 
to be looked at and the values changed. That may leads to artefacts when the 
number of an element is below the by standard used number. But this is already 
present. The developer can prevent the behaviour (through transformations 
between block and dom/xml representation). An additional mutator function may 
eliminate the occurrence of artefacts as well. 

I hope I could make clear what I think and suggest, and also hope that it makes 
sense. 
If you have any questions please ask and even if the idea is not worth a doing 
(because of whatever reason) please tell me.

Best regards
Marc Wollenweber 

Original issue reported on code.google.com by borntob...@googlemail.com on 12 Mar 2013 at 10:29

[GoogleCodeExporter]

> "For mutator enabled blocks not all information are visible within the xml 
representation"

I believe this is false.  Here is the XML for an if/elseif/elseif:
<xml>
  <block type="controls_if" inline="false" x="46" y="42">
    <mutation elseif="2"></mutation>
  </block>
</xml>
Without this one couldn't use XML to save and restore blocks.

Please reopen if I have misunderstood.

Original comment by neil.fra...@gmail.com on 12 Mar 2013 at 11:39

• Changed state: Invalid

[GoogleCodeExporter]

Hey, you are right about the XML representation. In my case i don't use the XML 
representation to create a block but "new Blockly.Block ()" . In order to 
modify the block (setTitleValue, etc) I require the input area names and in the 
case of the mutator the names of the mutator count variables. They are not 
known. At the moment it is sufficient to add "Count_" to the mutator attributes 
within the mutator child element. But this is not mandatory, just true for the 
moment.

But you can stick with the actual realisation, I just thought it would separate 
the mutator feature from the rest. 

Best regards

Original comment by borntob...@googlemail.com on 13 Mar 2013 at 12:09