Attribute Blocks occasionally incorrectly show order and infix

[Gauntlet173]

occasionally, a new attribute declaration block for a true / false attribute will incorrectly appear with the "order" and "infix" fields visible, until it is reloaded.

I suspect what is happening is that the block is taking its default form (not apply the mutation), because it doesn't have a value from the type dropdown, because the type dropdown has not updated itself from the list of available categories, yet. The delay is short, but it might be long enough to cause that problem.

I suspect that the solution is to cache the current value of the type dropdown on the block as a separate mutation from the field, and use the value of the mutation, not the value of the field, to determine the block shape in the mutation code.

[Gauntlet173]

This problem also results in incorrect code generation in certain circumstances, which can lead to existence errors when running queries against the reasoner endpoints. High priority to fix this using the method proposed above.

[Gauntlet173]

I have followed up with Google.

[Gauntlet173]

No response from google mail list.

[Gauntlet173]

Might be related to #428

[Gauntlet173]

When I was implementing the new relationship blocks, I noticed that there is a listener that is doing the job of a mutator for some blocks. That might be a source of the problem. Whatever blocks have this problem, look at re-implementing them in the style of the relationship declaration block.

[Gauntlet173]

I've given up on waiting for feedback. I'm just going to have to figure it out without their help.

[Gauntlet173]

This is preventing me from being able to build examples, so it has become urgent.

[Gauntlet173]

After playing with it for a while, I think this has been resolved in v1.6.11-alpha