feature request #9038
closedAdapt TaxEditor to use BigDecimal for StatisticalMeasurementValues
60%
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
Related issues
Updated by Andreas Müller almost 4 years ago
- File picture479-1.png picture479-1.png added
- Description updated (diff)
Updated by Katja Luther almost 4 years ago
- Status changed from New to In Progress
The label issue is caused by the DefaultQuantitativeDescriptionBuilder because exact values are not handled.
Updated by Katja Luther almost 4 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?
Updated by Andreas Müller almost 4 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.
Updated by Katja Luther almost 4 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.
Updated by Andreas Müller almost 4 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 "."
Updated by Andreas Müller almost 4 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.
Updated by Andreas Müller almost 4 years ago
Please be aware of #9059 when testing this
Updated by Katja Luther almost 4 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.
Updated by Andreas Müller almost 4 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.
Updated by Andreas Müller almost 4 years ago
- Related to feature request #8978: Implement measurement values as BigDecimal added
Updated by Andreas Müller almost 4 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."
Updated by Andreas Müller almost 4 years ago
- % Done changed from 50 to 80
Can you please review my changes and if ok close the ticket?
Updated by Andreas Müller almost 4 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.
Updated by Katja Luther almost 4 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).
Updated by Andreas Müller almost 4 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?
Updated by Katja Luther almost 4 years ago
- Related to feature request #9080: Use detailElement of quantitative data in dialog of character matrix added
Updated by Katja Luther almost 4 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
Updated by Katja Luther almost 4 years ago
- Status changed from Feedback to Closed