-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
There should be error when there is no converter to the model element #3818
Comments
Would it be ok to have an element without view, so basically no need for conversion? |
Right now not. Every model element should have a corresponding view. There might be a view element without a model, but not the opposite. We may consider introducing model elements without views in the future, but these will be special situations and I believe they should be marked somehow. |
I'm thinking about elements that hold metadata or that are not to be visible in a specific view context, like HTML comments, for example. |
Such elements, if possible, should be done using positions or attributes. HTML Comment could be converted to view/dom. |
Ofc, there is always a way to hack things and make it work, still we should not exclude the possibility of elements that have no view element. Just had another example. The alternative text of an image could be the child element of the image element in the Model. There would be no element for it in the editing view and we could just output it in the final HTML. Ofc, there are ways to make it different, but here you got another example. |
I think that I agree with @fredck on this. We've seen the situation where less elements in the model convert to more elements in the view. We may also see the opposite. And, like in the lists case, we'll always have an option which way to go (because we can always extract that data somewhere else to ensure 1:1 mapping between the model and the view). But if we say that the model must be as close to the view as possible, then we're negating a bit its sense. At the same time, I understand technological limitations. If this kind of mapping is hard to achieve for some reason, then we could live without it. But we should at least try (just like we did with lists). Because the more options we get, the better flexibility and power. |
👍 |
I think you mixed two topics here. This one is about: as long as there must be a converter for each model element we should throw errors to make debugging simpler. It is a part of the bigger issue: debugging converters it far to complicated, and even I, knowing almost every line of the code there, wants to cry when I meet a bug in conversion. We could consider changes in the conversion to allow model elements without converters, but this is much bigger topic then adding a simple |
I've just wasted 1h trying to understand an error and guess what, it was of course a missing converter. |
What about having a default converter that is used automatically in such cases? So we'll always have converters attached to model elements, but developers would not need to care about creating them. |
Today @oskarwrobel met this problem. For sure we need to fix it soon. |
Faced this problem once again. I forgot about m->v converter after switching from Virtual to Classic Test Editor and I got a very unclear exception. |
Related ticket: #6538. |
This will be resolved in #10377. |
Each model element should have a converter. There should an error or warning when there is no converter to the model element. Now nothing happens, you do not get the element in the view, and get an error, at some point later when you add another element. Error or warning should appear immediately when you add that element to the model.
The text was updated successfully, but these errors were encountered: