enforcement of type's label configuration during creation of topics via the rest-server

[Malte]

For me it now looks like that labels of newly created topic instances depend on the order of fields in the composite-object send to the rest-server. Maybe the enforcement of a type's label configuration at server side is the desired behavior here.

Example: In the case you bookmarked a web resource with the firefox extension, the "description" field is taken as label in this listing.. but as soon as you edited this or created a completely new "Web Resource" within the dm4-webclient, the "url"-field has precedence as a label (in this listing). When using the dm4.0.5 release.

Area or Module of this ticket should be set to "Server", i guess.

[jri]

Yes, when DM applies the default label rule it should respect the child-type order of the *type definition*, instead of operating on the child-type order of the very *composite object* that is used for the create or update operation. This should be fixed in DM.

For the moment try to put the URL *before* the Description in the composite object used for the create operation. This should result in a correct label -- that is the Web Resource's URL.

Background: the out-of-the box DM installation specifies no label rule for the Web Resource type. So the default rule applies: take the first simple child type met while a depth-first traversal. This is the Web Resource's URL. This is the intended out-of-the box behavior.

If you want a custom label:

• change the Web Resource's label rule by the means of a DM migration. Take into account that this will apply globally, thus changing the labeling in the DM webclient as well.

OR:

• Do not rely on the topic's value (=label) when building your FF extension's resource listing, but construct the list item's label from the topic's composite value. So, you have to fetch the Web Resources with fetch_composite=true

If you want the list items look like JuergeN's suggestion (https://trac.deepamehta.de/ticket/101#comment:7) you have to go for the latter option.

[jri]

I wrote:

So, you have to fetch the Web Resources with fetch_composite=true

For the "get-topics-by-type" service call (REST API: /core/topic/by_type) a fetch_composite parameter is only provided in master (4.0.6-SNAPSHOT), not in 4.0.5

See ​https://github.com/jri/deepamehta/commit/113f6426989231af68c3bac9fdead7c6e42c1e1b

However, I recommend to stay at 4.0.5 for the moment as the 4.0.6-SNAPSHOT is considered unstable (API has changed and will change again). So, as a workaround you have to request the Web Resource topics one-by-one. In this case fetch_composite is true by default.

[Jörg Richter]

Core: fix labeling Pt.2 (#145).

Close ticket 145.

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

[Jörg Richter]

Core: fix labeling Pt.2 (#145).

Close ticket 145.

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

[Jörg Richter]

Core: fix labeling Pt.2 (#145).

Close ticket 145.

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