Open childen opened 5 months ago
Hi @childen,
Thanks for reporting this! The Single and Multi Choice fields are almost implemented but not quite there yet. The progress is tracked here: https://github.com/strictdoc-project/strictdoc/issues/1076.
It looks like you are hitting the same issue as @haxtibal. StrictDoc has a not so well explained convention about single- and multi-line fields convention which he documented here just yesterday. Please check his documentation update, and let me know if slightly changing your grammar would fix the issue: https://github.com/strictdoc-project/strictdoc/pull/1898.
@haxtibal already suggested that the single/multiline fields could be placed below the statement field but be always treated as single-line fields. This could be a good option for overcoming this limitation.
@stanislaw thank you for the clarification. Moving the field solves the issue in the dev environment.
Should we close this issue or keep it around to track one of the following solutions?
Let's not close this issue. I will do the following:
Add a validation to the grammar validator in the CLI interface as well as in the UI interface. Both messages will prevent a grammar with this issue's example from being created.
This will satisfy the point 2 and will make the point 1 solved at the same time.
I am not happy with this convention but I don't know of a better way of handling this. Here is a fragment of my recent discussion with @haxtibal:
Hi @Tobias Deiminger . You are the first to hit and consider this seriously.
Currently, there is a gray area with a convention: every field which is before the content field is singleline (with your recent feedback, the content field is now STATEMENT/DESCRIPTION/CONTENT).
There are simple cases when StrictDoc must know whether it is dealing with a single or multi-line field. For example, you cannot receive a multiline value for the UID field, and this is where all the newline characters must be stripped. The same for TITLE. The cases like this made me to introduce this convention: if a field is before the content field, it is considered meta information and is assumed to be single-line. All fields after the content field are assumed to be multiline. An alternative I was considering for a long time was to make it explicit in the grammar that a field could be SinglelineString or MultilineString but I didn't get to implementing that yet and that would also enforce every field to have just one syntax: normal string or <<< >>>. I thought about making SingleChoice and MultipleChoice to be treated as single-line strings but didn't get to doing it 😦 The documentation could be doing a better job, indeed. How would you prefer to have it?
When I consider it from the strict-ness perspective, my clear preference would be to split the String type into Single/Multiline String types. But that would be another migration that has to preserve backward compatibility and still maintain the convention <= content field. So I guess the documentation has to explain this in any case as the first step.
Do you think you could contribute a sentence to the documentation, explaining this clearly just the way you yourself would like to have seen it when reading for the first time?
And then the response from @haxtibal:
My initial assumption was that one can define Single/MultipleChoice fields anywhere - and I did not think about whether they could be multiline at all. Regarding grammer I would probably find an explicit multiline string a bit confusing, just because I never saw such a distinction in any programming language. A string is a string, and if it contains \n it has multiple lines, that's it 🙂 Everything is actually ok for us as of now. Knowing that these fields must be defined before the content field is enough. I can contribute such a sentence.
Steps to reproduce:
For me the edit window stays open and no error is displayed. Additionally the backend prints the following error message:
NotImplementedError: Field STATUS must be a single-line field.
Backtrace: