Ticket #145 (closed Defect: fixed)

Opened 13 years ago

Last modified 13 years ago

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

Reported by: Malte Owned by:
Priority: Minor Milestone:
Component: DeepaMehta Standard Distribution Version: 4.0.5
Keywords: Cc: JuergeN
Complexity: 3 Area:


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.

Change History

comment:1 follow-up: ↓ 2 Changed 13 years ago by jri

  • Cc JuergeN added

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.


  • 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.

Last edited 13 years ago by jri (previous) (diff)

comment:2 in reply to: ↑ 1 Changed 13 years ago by 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.

Last edited 13 years ago by jri (previous) (diff)

comment:3 Changed 13 years ago by Jörg Richter

  • Status changed from new to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.