Editor for aggregated composites

[jri]

Meanwhile the Core processes update requests where aggregated composites are involved (see #30). Now the GUI needs to be put on a par.

These operation should be possible within the parent form:

• Assigning *existing* aggregated composite(s) to the parent topic.
• Removing assignments of aggregated composite(s) (for "many" cardinality).
• possibly: Creation of new aggregated composite(s) and assigning to the parent topic.

This operation will deliberately NOT be addressed:

• Editing the *contents* of an aggregated composite within the parent form (see comments on #30). To edit the content the user is supposed to deliberately edit the composite directly (in its own form).

[Jörg Richter]

Core: fix updating aggregated composites (#574).

When updating an aggregated composite no error occurs.

As a by-product of that fix you can now have aggregated composites in your model and edit such a complex topic via the Webclient. This works now for the first time with the Webclient's standard renderers (see #30).

So a first version of what we called a "Editor for aggregated composites" (see #337) is now available. However it is just in its first incarnation that will possibly not survive for long. In its current form it realizes the most cautious approach in regard of unwanted semantic side effects (see comments in #30): every time an aggregated composite is edited a new instance of the composite is created. Thus a lot of possibly useless (because unassigned) topics remain in the DB.

CHANGES

Core API: there is a new model class:

de.deepamehta.core.model.TopicReferenceModel

A reference to a topic, either by ID, or by URI.

BREAKING CHANGES

The Core Service's composite object update logic does not rely on a fallible heuristic to detect weather a TopicModel? represents actually a topic reference (based on ID and URI) but utilizes explicit TopicReferenceModel? instances for that purpose (analogous to TopicDeletionModel?).

When your plugin creates a TopicModel? object to represent a reference (e.g. to pass it to the Facet Service's updateFacet() call) you must now create a TopicReferenceModel? instead. Otherwise your update call will throw an error resp. have unexpected results.

See #574.

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

[Jörg Richter]

Editor for aggregated composites (#337).

You can now have aggregated composites in your data model and can edit such complex topics in the Webclient's detail panel. However, the current implementation differs from what is described in the original ticket. The current implementation is pragmatic, the usage is intuitive, and no proliferating topic copies are created. For example you can edit a Person's address right in the Person form, even if Address would be defined via Aggregation Definition.

"semantic side effects" (see comments in #30) are possible in principle but only when associations are manipulated manually. In the scenario of an aggregated Address you can assign the same Address instance to 2 persons by manually creating an association. (Note: when editing via detail panel one Address instance is currently never assigned to 2 Persons.) In that case, when you edit the Address via Person 1 in the page panel, it changes for Person 2 as well. You can consider that as a "semantic side effect".

In some cases that is exactly what you want, in others it is not. However, that's the way the Webclient works for now. Regarding development effort it reflects the most pragmatic solution. The underlying semantic problem is conceptually huge, and in the way I see it there no general solution exists except further complicating the meta model and/or the GUI, which I feel is not desirable.

Future strategy:

• The GUI could be extended in the way described in the ticket. It could support the creation of aggregated composites that are actually shared between various parents.
• Different form rendering and processing behavior is realizable by custom page renderers.

See #337.

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