Closed martin-fleck-at closed 1 month ago
3 files ±0 30 suites ±0 2m 25s :stopwatch: -13s 71 tests ±0 71 :white_check_mark: ±0 0 :zzz: ±0 0 :x: ±0 216 runs ±0 216 :white_check_mark: ±0 0 :zzz: ±0 0 :x: ±0
Results for commit b908225e. ± Comparison against base commit bced5de4.
:recycle: This comment has been updated with latest results.
@harmen-xb Not sure why the MacOS build keeps failing but I'll keep re-triggering in case it is outside of our control for now and will check up on it tomorrow again.
@harmen-xb Hopefully fixed it by providing the GITHUB_TOKEN and increasing the rate limit from 60/hour to 1000/hour supposedly.
@martin-fleck-at
The changes look pretty good, the tabbing perspectives is nice.
I do notice some strange behaviour when working in the code editor. When I for example open the 'CalcAge' entity and then edit the file which would make the file invalid according to the grammer. Untill savind it's fine, but when you press Save it removes all parts in the file which are invalid. Why don't we leave the file in a invalid state for the user to be fixed?
Example of a change, remove the double quotes around the name of an attribute (which is incorrect but fixable by the end-user). When you the press Save the whole name part is gone.
Or when you remove the double quotes around the name of the entity, the name element is gone, nut also everything else in the files. So it looks like the serializer stops on an error but still returns the fill as far as it could serialize it. But in this case it should not serialize it again, just leave the file as is and leave the errors in.
@martin-fleck-at
The changes look pretty good, the tabbing perspectives is nice.
I do notice some strange behaviour when working in the code editor. When I for example open the 'CalcAge' entity and then edit the file which would make the file invalid according to the grammer. Untill savind it's fine, but when you press Save it removes all parts in the file which are invalid. Why don't we leave the file in a invalid state for the user to be fixed?
Example of a change, remove the double quotes around the name of an attribute (which is incorrect but fixable by the end-user). When you the press Save the whole name part is gone.
Or when you remove the double quotes around the name of the entity, the name element is gone, nut also everything else in the files. So it looks like the serializer stops on an error but still returns the fill as far as it could serialize it. But in this case it should not serialize it again, just leave the file as is and leave the errors in.
Interesting, I'll have a deeper look at this tomorrow but my best guess is that the parser actually only creates parts of the internal model (as far as it can) and that is what we in the end serialize since we always serialize the in-memory representation.
@martin-fleck-at The changes look pretty good, the tabbing perspectives is nice. I do notice some strange behaviour when working in the code editor. When I for example open the 'CalcAge' entity and then edit the file which would make the file invalid according to the grammer. Untill savind it's fine, but when you press Save it removes all parts in the file which are invalid. Why don't we leave the file in a invalid state for the user to be fixed? Example of a change, remove the double quotes around the name of an attribute (which is incorrect but fixable by the end-user). When you the press Save the whole name part is gone. Or when you remove the double quotes around the name of the entity, the name element is gone, nut also everything else in the files. So it looks like the serializer stops on an error but still returns the fill as far as it could serialize it. But in this case it should not serialize it again, just leave the file as is and leave the errors in.
Interesting, I'll have a deeper look at this tomorrow but my best guess is that the parser actually only creates parts of the internal model (as far as it can) and that is what we in the end serialize since we always serialize the in-memory representation.
I get that, but I think if the parser fails it should not serialize it. If the edit comes from the code editor it shouldn't serialize it anyway I think.
I guess this is also related to if the file is invalid, the other perspectives should be disabled untill the file is fixed I think. This definetly a new thing, so not for now.
@harmen-xb I fixed the issue you mentioned and also introduced a readonly mode for our widgets to notify the user.
@martin-fleck-at
The code editor now works as expected, I can type anything I want (also grammitcally incorrect) and save it. And the form/diagram nicely shows the error about a broken model.
2 things:
@harmen-xb I updated the message and fixed the handling in the form editor. Indeed, that was a problem that was already present before this change that in the form editor you could only undo once. However, now it should be possible to undo at least all the changes done by the form editor itself.
@martin-fleck-at The changes look good.
I do think you use the wrong log level for writing the ModelReducer en form-editor outputs. There is a bit to much info logging now I think :).
@harmen-xb I reduced the log level to debug. If you agree with that, feel free to approve and merge the PR
Add composite editor containing all other editors
Additional: