Project

General

Profile

feature request #9038

Adapt TaxEditor to use BigDecimal for StatisticalMeasurementValues

Added by Andreas Müller 4 months ago. Updated 3 months ago.

Status:
Closed
Priority:
New
Assignee:
Category:
taxeditor
Target version:
Start date:
05/28/2020
Due date:
% Done:

60%

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)

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


Related issues

Related to Edit - feature request #8978: Implement measurement values as BigDecimal Closed 04/25/2020
Related to Edit - feature request #9080: Use detailElement of quantitative data in dialog of character matrix New 06/18/2020

Associated revisions

Revision bf20bbfd (diff)
Added by Katja Luther 4 months ago

adapt editor to value of statisticalMeasurementValue as BigDecimal

Revision 95c53d84 (diff)
Added by Katja Luther 4 months ago

ref #9038: add exact value to DefaultQuantitativeDescriptionBuilder

Revision 3d126815 (diff)
Added by Katja Luther 4 months ago

ref #9038: do not set big decimal value to 0.0 if field is cleared

Revision 7801652a (diff)
Added by Andreas Müller 4 months ago

ref #9038 move DescriptionBuilder to model.format

Revision f758df66 (diff)
Added by Katja Luther 4 months ago

ref #9038: fix formatter for exact values

Revision e6381e99 (diff)
Added by Katja Luther 4 months ago

ref #9038: use QuantitativeDataFormatter for formating the label

Revision d002d872 (diff)
Added by Katja Luther 4 months ago

ref #9038: check value with regex if fit in BigDecimal

Revision 5c875358 (diff)
Added by Andreas Müller 4 months ago

ref #9038 slightly adapted the regEx for StatisticalMeasurementValue BigDecimal

Revision e00b2687 (diff)
Added by Andreas Müller 4 months ago

ref #9038 fix handling of null values for StatisticalMeasurementValue (comments still need to be removed)

Revision d08aa271 (diff)
Added by Andreas Müller 4 months ago

ref #9038 try to fix regEx compile error

Revision 55937de8 (diff)
Added by Andreas Müller 3 months ago

ref #9038 try to improve BigDecimal handling in TaxEditor

Revision b627e8ef (diff)
Added by Andreas Müller 3 months ago

ref #9038 further improve BigDecimal handling in TaxEditor

History

#1 Updated by Andreas Müller 4 months ago

#2 Updated by Andreas Müller 4 months ago

  • Description updated (diff)

#3 Updated by Katja Luther 4 months ago

  • Status changed from New to In Progress

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

#4 Updated by Katja Luther 4 months 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?

#5 Updated by Katja Luther 4 months ago

  • % Done changed from 0 to 50

#6 Updated by Andreas Müller 4 months 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.

#7 Updated by Andreas Müller 4 months ago

  • % Done changed from 0 to 50

#8 Updated by Katja Luther 4 months 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.

#9 Updated by Andreas Müller 4 months 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 "."

#10 Updated by Andreas Müller 4 months 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.

#11 Updated by Andreas Müller 4 months ago

Please be aware of #9059 when testing this

#12 Updated by Katja Luther 4 months 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.

#13 Updated by Andreas Müller 4 months 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.

#14 Updated by Andreas Müller 4 months ago

#15 Updated by Andreas Müller 3 months 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."

#16 Updated by Andreas Müller 3 months ago

  • % Done changed from 50 to 80

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

#17 Updated by Katja Luther 3 months ago

  • Status changed from Resolved to Closed

looks good.

#18 Updated by Andreas Müller 3 months 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.

#19 Updated by Katja Luther 3 months 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).

#20 Updated by Andreas Müller 3 months 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?

#21 Updated by Katja Luther 3 months ago

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

#22 Updated by Katja Luther 3 months 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

#23 Updated by Katja Luther 3 months ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 40 MB)