Aggregated composits not yet implemented

[jri]

Type definitions:

• compositions with a simple type as child works
• compositions with a complex type as child works
• aggregations with a simple type as child works
• aggregations with a complex type as child is NOT YET IMPLEMENTED

Simple type here means: "Text", "Number", "Boolean", "HTML"
Complex type means: "Composite"

[Jörg Richter]

Core: update aggregated composites (#30).

The core service now processes update requests where aggreagted composite child topics are involved.
The "Aggregation of composite topic types not yet supported" exception is not thrown anymore.

However, such a request can only be used to

1) assign an existing topic as child (request contains a ref_id: or ref_uri: part)
2) create a new topic and assign it as child (request contains a simple value or a topic model whose ID is -1)

Such a request can not be used to update the *contents* of an existing child.

IMPORTANT: plugins whose model involve aggregated composite childs should provide a custom renderer (single or multi) for them. The generic Webclient renderers do not work fully for the moment. Their info rendering and form rendering capabilities do work but content changes in aggregated child topics are ignored. Only the assignments are maintained (as listed above).

See ticket 30.

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

[Jörg Richter]

Core: update aggregated composites (#30).

The core service now processes update requests where aggreagted composite child topics are involved.
The "Aggregation of composite topic types not yet supported" exception is not thrown anymore.

However, such a request can only be used to

1) assign an existing topic as child (request contains a ref_id: or ref_uri: part)
2) create a new topic and assign it as child (request contains a simple value or a topic model whose ID is -1)

Such a request can not be used to update the *contents* of an existing child.

IMPORTANT: plugins whose model involve aggregated composite childs should provide a custom renderer (single or multi) for them. The generic Webclient renderers do not work fully for the moment. Their info rendering and form rendering capabilities do work but content changes in aggregated child topics are ignored. Only the assignments are maintained (as listed above).

See ticket 30.

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

[jri]

Despite the restriction mentioned in the comments this issue is considered completed for the moment.

The restriction is intentional. Updating the contents of an aggregated composite is a potentially dangerous operation as this could have semantic side effects. The composite could be used in other contexts as well and the update would affect them too.

In the application semantic 2 cases have to distinguish carefully:

1) The change is intended to affect *all* contexts
2) The change is intended to affect only one context. This requires creation of another object and maintaining the references.

Looking at the sole request these cases can't be distinguished.
So, it's to the application developer to decide which case is on the hand and possibly update the composite object explicitly.

[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