Call for Input! Removing deletable, movable, and editable attributes from the new serialization system

[Beka Westberg]

 Hello :D

For background: My project for the summer is Project Cereal, which intends to add a new JavaScript Object (JSO) serializer to Blockly. This serializer is in addition to the XML serializer, which will continue to work. Once it is released, using the JSO serializer is completely optional.

The purpose of this post is to gather feedback on whether the deletable, movable, and editable block attributes should be removed from this new system.

What

In the current system, you can specify whether your blocks are deletable, movable, or editable, or not using the XML:

```

<xml><block type="start_block" deletable="false" movable="false" editable="false"></block></xml>

```

This will continue to work. However, I am proposing there would not be equivalents in the JSO system.

Why

• It makes the save format more consistent.
  The serialized state only needs to include values which are directly user-modifiable (eg collapsed, disabled, field values, etc). Things that are only modifiable programmatically do not need to be serialized (eg block colour, warnings, etc).
  Since deletable, movable, and editable are only modifiable programmatically, they should not be serialized.
  For a further discussion of this see the comments on the field editablility PR.
• It fixes issue #2285 for the JSO serializer.
  Currently if you deserialize XML into a read-only workspace and then re-serialize it, you will get erroneous deletable, movable, and editable tags on every block. Not serializing those attributes makes that impossible.
• It makes the save format slightly smaller.
  But this is not a big factor, unless you have a lot of undeletable, unmovable, uneditable blocks.

    

Impact, Upgrade Paths and Workarounds

If we decide to remove these values this is what it looks like for you.

Firstly, this only applies if you want to use the JSO serializer. If you want to keep using the XML one, this doesn't impact you at all.

Option 1:

You can define the deletability, movability, and editability of your blocks using the setDeletable, setMovable, and setEditable functions within your block definition. For example this:

```

<xml><block type="start_block" deletable="false" movable="false" editable="false"></block></xml>

```

Becomes this:

```

<xml><block type="start_block"></block></xml>

Blockly.Blocks['start_block'] = {

  init: function() {

    // Original code...

    this.setDeletable(false);

    this.setMovable(false);

    this.setEditable(false);

  }

}

```

Option 2:

You can create a plugin serializer which serializes these values, if you wish to keep serializing them. The JSO output would then probably look something like:

```

{

  "blocks": {

    "languageVersion": 0,

    "blocks": [ /* block info */ ]

  },

  "extraBlockAttributes": {

    "undeletable": [ /* block ids */ ],

    "unmovable": [ /* block ids */ ],

    "uneditable": [ /* block ids */ ],

  }

}

```

Feedback

Any thoughts on this proposal are very much appreciated! I'm especially interested in situations where you have a block that is sometimes undeletable/unmovable/uneditable and other times it is not.

Any other comments/thoughts/questions are very much appreciated as well! Feel free to reply here, or message me directly =)

If there is no feedback, these attributes will probably be removed.

Thank you for your time,

Beka

[Uwe K]

Hello,

we have a need for the undeletable field. We store workspaces that are based on different project types. A project type is a toolbox and a starting workspace. The starting workspaces often contain undeletable event blocks which are not available in the toolbox. Other event blocks are part of the toolbox (and deletable). The same block might be undeletable in one project type but deletable in another.

[Beka Westberg]

Hello,

Thank you so much for your feedback :D That's good to know.

I've also learned that BlocklyGames does something similar, where event/hat blocks are initially undeletable, and as you progress through the levels they become deletable. In that case it seems like it will probably be best to leave these attributes in. But it does kind of hurt me to reintroduce a known bug (#2285) into a new system.

If Blockly provided (aka I built) a plugin for serializing these attributes separately (as suggested by Option 2 above) would that work for your project?

Thank you again for your feedback! I really appreciate you taking the time to reply :D

--Beka

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/cf647f51-ff47-4ce0-9812-4c46dd7da262n%40googlegroups.com.

[Uwe K]

No problem. Yes, as I understand it, such a plugin would solve the issue.