Skip to content
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

Closed
pjasiun opened this issue Sep 15, 2016 · 14 comments
Closed

There should be error when there is no converter to the model element #3818

pjasiun opened this issue Sep 15, 2016 · 14 comments
Labels
domain:dx This issue reports a developer experience problem or possible improvement. package:engine resolution:duplicate This issue is a duplicate of another issue and was merged into it. squad:core Issue to be handled by the Core team. type:improvement This issue reports a possible enhancement of an existing feature.

Comments

@pjasiun
Copy link

pjasiun commented Sep 15, 2016

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.

@Reinmar Reinmar changed the title There should error when there is no converter to the model element There should be error when there is no converter to the model element Sep 15, 2016
@fredck
Copy link
Contributor

fredck commented Sep 15, 2016

Would it be ok to have an element without view, so basically no need for conversion?

@pjasiun
Copy link
Author

pjasiun commented Sep 15, 2016

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.

@fredck
Copy link
Contributor

fredck commented Sep 15, 2016

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.

@scofalik
Copy link
Contributor

Such elements, if possible, should be done using positions or attributes. HTML Comment could be converted to view/dom.

@fredck
Copy link
Contributor

fredck commented Sep 16, 2016

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.

@Reinmar
Copy link
Member

Reinmar commented Sep 16, 2016

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.

@fredck
Copy link
Contributor

fredck commented Sep 16, 2016

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.

👍

@pjasiun
Copy link
Author

pjasiun commented Sep 16, 2016

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 throw. You can create a ticket for it, if we want to consider it for real now.

@Reinmar
Copy link
Member

Reinmar commented Dec 8, 2016

I've just wasted 1h trying to understand an error and guess what, it was of course a missing converter.

@fredck
Copy link
Contributor

fredck commented Dec 8, 2016

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.

@pjasiun
Copy link
Author

pjasiun commented Feb 5, 2018

Today @oskarwrobel met this problem. For sure we need to fix it soon.

@oskarwrobel
Copy link
Contributor

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.

@mlewand mlewand transferred this issue from ckeditor/ckeditor5-engine Oct 9, 2019
@mlewand mlewand added this to the nice-to-have milestone Oct 9, 2019
@mlewand mlewand added status:confirmed type:improvement This issue reports a possible enhancement of an existing feature. package:engine labels Oct 9, 2019
@Reinmar Reinmar added the domain:dx This issue reports a developer experience problem or possible improvement. label Apr 2, 2020
@Reinmar
Copy link
Member

Reinmar commented Apr 2, 2020

Related ticket: #6538.

@Reinmar Reinmar modified the milestones: nice-to-have, next Apr 2, 2020
@pomek pomek modified the milestones: next, nice-to-have Nov 10, 2020
@Reinmar Reinmar added squad:core Issue to be handled by the Core team. and removed squad:dx labels Sep 8, 2021
@Reinmar
Copy link
Member

Reinmar commented Sep 27, 2021

This will be resolved in #10377.

@Reinmar Reinmar closed this as completed Sep 27, 2021
@Reinmar Reinmar removed this from the nice-to-have milestone Sep 27, 2021
@Reinmar Reinmar added the resolution:duplicate This issue is a duplicate of another issue and was merged into it. label Sep 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain:dx This issue reports a developer experience problem or possible improvement. package:engine resolution:duplicate This issue is a duplicate of another issue and was merged into it. squad:core Issue to be handled by the Core team. type:improvement This issue reports a possible enhancement of an existing feature.
Projects
None yet
Development

No branches or pull requests

8 participants