Core: revise aggregation update logic

[jri]

Currently Core's aggregation update logic is: first delete *all* existing ones and then (re)create the ones contained in the update request.

This is not workable for a couple of reasons:

• it is more cumbersome for the plugin developer to construct the update request as she must redundantly include all the existing aggregations.
• it is inefficient: all the context of the (unnecessarily) deleted aggregation must be restored. That includes at least the Workspace, Creator, and Owner assignments, and ACL entries.
• it confuses the Webclient user as recreated aggregations disappear from the view.

The better approach is to explicitly include "delete aggregation" instructions in the update request (by the means of the del_id: prefix).

[Jörg Richter]

Core: revise aggregation update logic (#319).

Unchanged aggregations are not unnecessarily deleted (and restored) anymore.

Functional in principle, but not yet complete:

• For many-aggregations the property panel is only up-to-date after topic reselection.
• The checkbox multi-renderer is not yet adapted.

IMPORTANT for plugin developers:
To explicitly remove child topic assignments in many-aggregations you must include the del_id: prefix in the update request. On the other hand you're no longer required to include all the unchanged assignments in the request.

The del_id: prefix works now for both, compositions and aggregations.

For one-aggregations a new child topic assignment automatically removes an existing one. The del_id: prefix is not required here (and it is even not yet suported, that is, for one-aggregations you cant remove the existing single assignment.)

See ticket 319.

• Changeset: 1e68fd9e72066691758d521eb0e910963a9896d0
• URL: ​https://github.com/jri/deepamehta/commit/1e68fd9e72066691758d521eb0e910963a9896d0

[Jörg Richter]

Core fix: aggregation update refreshes GUI (#319).

Once a form is submitted the property panel reflects the changes immediately.

Composition update code is refactored.

CompositeValue?:

• add() is new method
• remove() is new method

These are to be used for multiple-value childs.

See ticket 319.

• Changeset: baa4ec48780dd90939d29f4902fc65e472fceae1
• URL: ​https://github.com/jri/deepamehta/commit/baa4ec48780dd90939d29f4902fc65e472fceae1

[Jörg Richter]

Core: idempotent child update operations (#319).

These update child operations are idempotent now:

• delete child (composition many)
• delete child assignment (aggregation many)
• create child assignment (aggregation many)

So, an update request can contain e.g. del_id: prefixes to refer to child topics which are deleted already (compositions) resp. not assigned anymore (aggregations). This is not an error anymore. Instead, these partial update operations are ignored. The same applies to the ref_id: prefix when refering to a topic which is already assigned (aggregations).

Furthermore in Webclient:
The Checkbox Renderer is adapted to the Core's revised update logic.

CompositeValue?:

• put(String key, List<TopicModel?> value) is dropped. Use add multiple values use add() consecutively.

Close ticket 319.

• Changeset: d1e31c3075bb7f7a1d9589fa85d903241cb89211
• URL: ​https://github.com/jri/deepamehta/commit/d1e31c3075bb7f7a1d9589fa85d903241cb89211

[Jörg Richter]

Core: revise aggregation update logic (#319).

Unchanged aggregations are not unnecessarily deleted (and restored) anymore.

Functional in principle, but not yet complete:

• For many-aggregations the property panel is only up-to-date after topic reselection.
• The checkbox multi-renderer is not yet adapted.

IMPORTANT for plugin developers:
To explicitly remove child topic assignments in many-aggregations you must include the del_id: prefix in the update request. On the other hand you're no longer required to include all the unchanged assignments in the request.

The del_id: prefix works now for both, compositions and aggregations.

For one-aggregations a new child topic assignment automatically removes an existing one. The del_id: prefix is not required here (and it is even not yet suported, that is, for one-aggregations you cant remove the existing single assignment.)

See ticket 319.

• Changeset: 1e68fd9e72066691758d521eb0e910963a9896d0
• URL: ​https://github.com/jri/deepamehta/commit/1e68fd9e72066691758d521eb0e910963a9896d0

[Jörg Richter]

Core fix: aggregation update refreshes GUI (#319).

Once a form is submitted the property panel reflects the changes immediately.

Composition update code is refactored.

CompositeValue?:

• add() is new method
• remove() is new method

These are to be used for multiple-value childs.

See ticket 319.

• Changeset: baa4ec48780dd90939d29f4902fc65e472fceae1
• URL: ​https://github.com/jri/deepamehta/commit/baa4ec48780dd90939d29f4902fc65e472fceae1

[Jörg Richter]

Core: idempotent child update operations (#319).

These update child operations are idempotent now:

• delete child (composition many)
• delete child assignment (aggregation many)
• create child assignment (aggregation many)

So, an update request can contain e.g. del_id: prefixes to refer to child topics which are deleted already (compositions) resp. not assigned anymore (aggregations). This is not an error anymore. Instead, these partial update operations are ignored. The same applies to the ref_id: prefix when refering to a topic which is already assigned (aggregations).

Furthermore in Webclient:
The Checkbox Renderer is adapted to the Core's revised update logic.

CompositeValue?:

• put(String key, List<TopicModel?> value) is dropped. Use add multiple values use add() consecutively.

Close ticket 319.

• Changeset: d1e31c3075bb7f7a1d9589fa85d903241cb89211
• URL: ​https://github.com/jri/deepamehta/commit/d1e31c3075bb7f7a1d9589fa85d903241cb89211