Ticket #588 (closed Defect: fixed)

Opened 10 years ago

Last modified 10 years ago

Different behaviour in AggregstionDefinition depending on datatype

Reported by: silke Owned by: jri
Priority: Major Milestone: Release 4.2
Component: DeepaMehta Standard Distribution Version: 4.1.3
Keywords: Cc: dgf, Malte, JuergeN
Complexity: 3 Area:
Module: deepamehta-webclient


I find it very confusing that depending on the data type in a aggregation definition a text will only be created once, but a number will be created with every new instance. I think this is a bug.

Change History

comment:1 Changed 10 years ago by jri

  • Cc dgf, Malte added
  • Status changed from new to accepted
  • Module set to deepamehta-webclient
  • Milestone set to Release 4.2

Yes, you're right! This is inconsequent behavior.
Actually the aggregation semantics is not yet implemented for Number types (see also #240).
I'll fix that very soon.
Thank you for reporting!

comment:2 Changed 10 years ago by Jörg Richter

  • Status changed from accepted to closed
  • Resolution set to fixed

Webclient: aggregated numbers (#588, #240).

The aggregation semantics is now implemented for Number types as well.
Aggregated number instances are created only once (#588).
The user can select/enter an aggregated number via a combo box (#240).

GUIToolkit API:

Class Combobox has a new method:

  • val()

RenderHelper? API:

The dm4c.render object has 3 new methods:

  • form_element(page_model, parent_element)
  • form_element_function(form_element)
  • get_option_topics(page_model)

Close #588.
Close #240.

comment:3 Changed 10 years ago by jri

ADDENDUM: JuergeN was a little worried when I said "aggregation semantics" is now implemented for Text and Number data types, but still not for Boolean, HTML, and Composite.

State of affair is: in the backend aggregation semantics is implemented for ALL the data types (besides Composite vs non-Composite the backend doesn't care about data types at all). Update requests operating on aggregated data structures are properly processed by the backend in all cases. The Webclient on the other hand, does not construct such requests for aggregated Boolean, HTML, and Composite values. So, it's the GUI that does not yet support all cases. The backend already does.

This info dissolved JuergeN's concern. For the moment he regards the current solution as sufficient.

Note: See TracTickets for help on using tickets.