Allow defining target in attributeToAttrbibute conversion helpers

[Reinmar]

Typical problem – model and view structures don't match one another. Example:

model:
<image src="foo"></image>

view:
<figure class="image">
    <img src="foo">
</figure>

If you want to write a converter for let's say an id attribute that should be added on <img> a simple use of attributeToAttribute() will not work as expected, because the attribute will end up in the <figure>. That's because <image> is mapped to <figure>.

It's possible to work around this by using lower-level, event-based mechanism. You can find the solution here: https://github.com/ckeditor/ckeditor5-core/compare/poc/customfigureattributes

However, I think we can easily resolve this by adding viewTarget property:

editor.conversion.for( 'downcast' ).attributeToAttribute( {
	model: 'id',
	view: 'id',
	viewTarget: viewElement => {
		const imgViewElement = findImgElement( viewElement );

		return imgViewElement;
	}
} );

I'm not sure if upcast conversion requires a similar mechanism, but it's worth checking.

[Reinmar]

cc @jodator @scofalik

[Reinmar]

BTW, another addition to the conversion API that people are missing is #1589.

[jodator]

I wonder how this API could look like and if we should somehow restrict it.

Let's assume someone would go crazy and convert this id to id on some random node in the tree above current element just because it's doable (not a real problem TBH - but read below).

Now if we assume that the intended way of using this API is to point to a know inner child we might simplify it by:

1. providing a Matcher compatible object - to be used internally to find this element
2. providing callback that should return true/false
3. providing a callback that return the element

The idea behind 1/2 is such:

editor.conversion.for( 'downcast' ).attributeToAttribute( {
	model: 'id',
	view: 'id',
// 1.
	viewTarget: 'img'
// or 1.
	viewTarget: {
		name: 'img',
		classes: 'foo bar' // or whatever the API is...
	}
// or 2.
	viewTarget: viewChild => viewChild.is( 'img' )
} );

I think that such API might be a bit simpler and in line with other options that conversion API provides for defining view elements. Internally this could be a treewalker that iterates over the viewElement children (whole tree) (the mapped view element from the model element that holds this attribute).

The only problem I see in the above is how to restrict the depth of a search? Immediate children solves only figure > img problem but CKEditor allows theoretically to create deeper structrues. But, OTOH, I don't recall what would be available as view children - only a view structure from elementToElement() convertions or does the children will be converted also? If it's the first thing (so withouth model's children converted) the this would play nice.

---

Bottom line it looks like simple addition and I don't see potential risks but @scofalik may have additonal points to make here.

[Reinmar]

This issue affects #6325.

[Reinmar]

I wonder how this API could look like and if we should somehow restrict it.

Callback which gets the parent element and lets you return whatever you want. No more magic and no more options.

All other options, such as flat or deep search with mapper or a callback should be available in the view element API. This way these methods will be reusable in other places.

[CKEditorBot]

There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.

[CKEditorBot]

We've closed your issue due to inactivity over the last year. We understand that the issue may still be relevant. If so, feel free to open a new one (and link this issue to it).