Project

General

Profile

Actions

feature request #9038

closed

Adapt TaxEditor to use BigDecimal for StatisticalMeasurementValues

Added by Andreas Müller over 2 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
New
Assignee:
Category:
taxeditor
Target version:
Start date:
Due date:
% Done:

60%

Estimated time:
Severity:
normal

Description

for details see #8978

Man issues alread have been solved by bf20bbfd . Some issues did arise when I tested the new implementation. Therefore I created an explicit ticket for the adaptation.

Open issues:

  • no label is shown in facts view anymore if data exists:

  • it is not possible to fully empty the textfield, if I delete all content 0.0 is automatically set which is annoying when changing data
  • if a single incorrect character is added (e.g. "a" instead of a number the complete content is deleted and replaced by 0.0), better the content should stay but become red (open question: what to do if the data is stored in the state? How do we handle this problem elsewhere, e.g. URLs, DOIs, etc.)
  • some problems when storing data (needs further reasearch)

Files

picture479-1.png (15.2 KB) picture479-1.png Andreas Müller, 05/28/2020 11:19 AM

Related issues

Related to EDIT - feature request #8978: Implement measurement values as BigDecimal ClosedKatja Luther

Actions
Related to EDIT - feature request #9080: Use detailElement of quantitative data in dialog of character matrixNewKatja Luther

Actions
Actions #1

Updated by Andreas Müller over 2 years ago

Actions #2

Updated by Andreas Müller over 2 years ago

  • Description updated (diff)
Actions #3

Updated by Katja Luther over 2 years ago

  • Status changed from New to In Progress

The label issue is caused by the DefaultQuantitativeDescriptionBuilder because exact values are not handled.

Actions #4

Updated by Katja Luther over 2 years ago

now the incorrect state is not cleared, but the value is not stored. I had a look how it is handled for urls and the value is not stored as well but the old value is removed, is this the wanted behaviour?

Actions #5

Updated by Katja Luther over 2 years ago

  • % Done changed from 0 to 50
Actions #6

Updated by Andreas Müller over 2 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 50 to 0

Katja Luther wrote:

The label issue is caused by the DefaultQuantitativeDescriptionBuilder because exact values are not handled.

This is not yet fully correct as hte DefaultQuantitativeDescriptionBuilder can only handle exactly 1 value per statistical measure. This is correct for statistical values (the model will be changed in future to allow only exactly 1 such value). However, for ExactValue multiple values are possible which is not yet handled.

Maybe we should better use the eu.etaxonomy.cdm.format.description.QuantitativeDataFormatter which probably handles the problem correctly.
The DefaultQuantitativeDescriptionBuilder was developped for natural language description which is maybe not really needed here.
Or in future we should merge the 2 classes anyway.

Note: I also moved the DescriptionBuilder classes from api.service to model packate format as this is more suitable and over time we want to move all formatting there if possible.

Actions #7

Updated by Andreas Müller over 2 years ago

  • % Done changed from 0 to 50
Actions #8

Updated by Katja Luther over 2 years ago

  • Status changed from Feedback to Resolved
  • Assignee changed from Katja Luther to Andreas Müller

Changed from DefaultQuantitativeDescriptionBuilder to QuantitativeDataFormatter to create the label string. If the handling of values of wrong state is ok (see #4), this issue is solved. please review.

Actions #9

Updated by Andreas Müller over 2 years ago

  • Status changed from Resolved to Feedback
  • Assignee changed from Andreas Müller to Katja Luther

Katja Luther wrote:

now the incorrect state is not cleared, but the value is not stored. I had a look how it is handled for urls and the value is not stored as well but the old value is removed, is this the wanted behaviour?

For now this is ok, but maybe we can create a new ticket which handles this even better. The behavior should be like:

  • whenever you enter something that can not be parsed as a BigDecimal number the enter event should be canceled. This has 2 exceptions
    • entering only "-" should be allowed => saving this should result in null
    • entering "." at the end, e.g. "1.", should be allowed to allow furthering entering the decimal numbers => saving should behave as if there is no "."
Actions #10

Updated by Andreas Müller over 2 years ago

Another open issue:

if the scale or the precision is not according to the possible precisions/scales the data is not stored. So we need to include a check that these values are not exceeded. The regex should look something like "-?0-9(.0-9)?"

The currently allowed scale/precision is available in StatisticalMeasurementValue.value @Columns annotation.

Strange is that trying to store a number that does not match these values leads to an out-of-range exceptions if the non-decimal part is to large while trying to store a number with to many decimal numbers does not throw an exception but also does not get persisted which is dangerous.

Actions #11

Updated by Andreas Müller over 2 years ago

Please be aware of #9059 when testing this

Actions #12

Updated by Katja Luther over 2 years ago

  • Status changed from Feedback to Resolved
  • Assignee changed from Katja Luther to Andreas Müller

now the entered text is checked by a regular expression, please review.

Actions #13

Updated by Andreas Müller over 2 years ago

Numbers with >9 digits before the decimal sign are still allowed. I adapted the regex accordingly.

Also incorrect values were still stored as 0.0 . I also adapted the code for this.

Still need to test the changes.

Actions #14

Updated by Andreas Müller over 2 years ago

Actions #15

Updated by Andreas Müller over 2 years ago

  • Assignee changed from Andreas Müller to Katja Luther

I did some further adaptations. Some were incorrect but now I think it should work as expected (max pre-decimal numbers: 9, max decimal numbers: 9, only "-" does not make the field red and is interpreted as null, a number ending with "." is interpreted as the same number without ".", a number with no pre-decimal number like -.130 is interpreted like a number with "0."

Actions #16

Updated by Andreas Müller over 2 years ago

  • % Done changed from 50 to 80

Can you please review my changes and if ok close the ticket?

Actions #17

Updated by Katja Luther over 2 years ago

  • Status changed from Resolved to Closed

looks good.

Actions #18

Updated by Andreas Müller over 2 years ago

  • Status changed from Closed to Feedback
  • % Done changed from 80 to 60

The new field seems not to be used for entering values in the dialogs for the descriptive matrix. But this is the main place where quantitative data will be entered.

Actions #19

Updated by Katja Luther over 2 years ago

  • Assignee changed from Katja Luther to Andreas Müller

Andreas Müller wrote:

The new field seems not to be used for entering values in the dialogs for the descriptive matrix. But this is the main place where quantitative data will be entered.

This would mean a reconstruction of the dialog with formelements, therefore I would create a new ticket (at the moment all dialogs without formelements as far as I know).

Actions #20

Updated by Andreas Müller over 2 years ago

  • Assignee changed from Andreas Müller to Katja Luther

Katja Luther wrote:

Andreas Müller wrote:

The new field seems not to be used for entering values in the dialogs for the descriptive matrix. But this is the main place where quantitative data will be entered.

This would mean a reconstruction of the dialog with formelements, therefore I would create a new ticket (at the moment all dialogs without formelements as far as I know).

If this is the only way to do it we should go this way. Have you created such a ticket?

Actions #21

Updated by Katja Luther over 2 years ago

  • Related to feature request #9080: Use detailElement of quantitative data in dialog of character matrix added
Actions #22

Updated by Katja Luther over 2 years ago

Andreas Müller wrote:

Katja Luther wrote:

Andreas Müller wrote:

The new field seems not to be used for entering values in the dialogs for the descriptive matrix. But this is the main place where quantitative data will be entered.

This would mean a reconstruction of the dialog with formelements, therefore I would create a new ticket (at the moment all dialogs without formelements as far as I know).

If this is the only way to do it we should go this way. Have you created such a ticket?

-> #9080

Actions #23

Updated by Katja Luther over 2 years ago

  • Status changed from Feedback to Closed
Actions

Also available in: Atom PDF