Different behaviour in AggregstionDefinition depending on datatype

[silke]

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.

[jri]

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!

[Jörg Richter]

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.

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

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