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

Introduced additional conversion options for downcast conversion. #7773

Merged
merged 10 commits into from
Aug 10, 2020

Conversation

oskarwrobel
Copy link
Contributor

Suggested merge commit message (convention)

Feature: Introduced additional conversion options for downcast conversion. Closes #7628.


Additional information

For example – encountered issues, assumptions you had to make, other affected tickets, etc.

@oskarwrobel oskarwrobel requested a review from scofalik August 4, 2020 11:25
@@ -151,10 +151,11 @@ export default class DataController {
* @param {String} [options.trim='empty'] Whether returned data should be trimmed. This option is set to `empty` by default,
* which means whenever editor content is considered empty, an empty string will be returned. To turn off trimming completely
* use `'none'`. In such cases exact content will be returned (for example `<p>&nbsp;</p>` for an empty editor).
* @param {Object} [options.conversionOptions] Additional, custom configuration passed to the conversion process.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, let's talk about this. We can have one of three:

  1. The way you implemented it (and we think about the name).
  2. Having just one flat object ({ root: 'main', showSuggestions: true, foo: 'bar' }).
  3. Having two parameters (and we think about names).

What I don't like about current solution is that you need to specify additional "level" of object if you want to pass "conversion option":

editor.getData( { conversionOptions: { showSuggestions: true } } )

I don't like it. Let's talk about other options.

Having two parameters isn't perfect either:

editor.getData( {}, { showSuggestions: true } )

Having it flat is a bit messy and may be difficult to document, but would be the easiest to use:

editor.getData( { showSuggestions: true } )
editor.getData( { root: 'other' } )

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And when it comes to name, it should make sense from the user's perspective. conversionOptions doesn't make a lot of sense, especially if someone is not a programmer, does not know CKE5 internals and simply integrates editor and wants to use .getData().

resultOptions, resultConfiguration, dataOptions, dataConfiguration is the direction I'd go.

Or just having it all in a one, flat options object 🤷

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that having one object would be best. For example, an option like options.trim also make sense to be available during conversion. From the integrator's perspective, one will not be able to understand why showSuggestions is a conversion option and trim is not. This is an implementation detail that should be abstracted.

That's why one options object should be enough.

*/
convertInsert( range, writer ) {
convertInsert( range, writer, options = {} ) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure I like this parameter here -- because you have to then document it the way you did. Maybe we could handle it somehow differently?

For example, set a property of conversionApi at the beginning of .get() and clear at the end? Hmmm.

Or maybe it is fine. But I'd change the documentation. In this place of API docs noone is interested where this parameter is used. This is kind of integration detail. We can write in the tutorial that options passed in .get() are later available in conversionApi but what you described is too much.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct me if I'm wrong, but in the current form, we'd need to have an additional param in every event and method.

In that case, conversionApi would be better as it's already widely available.

Copy link
Contributor Author

@oskarwrobel oskarwrobel Aug 10, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we'd need to have an additional param in every event and method

Not in every, but in convertInsert() and convertMarkerAdd(). To those methods that are used in DataController#toView().

Copy link
Contributor Author

@oskarwrobel oskarwrobel Aug 10, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For me, it sounds good to set options directly to the conversionApi (at the beginning of DataController#toView()) and remove when the conversion is done (at the end of DataController#toView())

@scofalik
Copy link
Contributor

scofalik commented Aug 5, 2020

I left my notes. @Reinmar could you take a look at the API?

@scofalik scofalik self-requested a review August 5, 2020 14:15
@scofalik
Copy link
Contributor

scofalik commented Aug 7, 2020

After thinking for a while I think that I like the "flat object" solution the most.

@scofalik
Copy link
Contributor

scofalik commented Aug 7, 2020

I'd document the options object this way:

* @param {Object} [options] Additional configuration for the retrived data. `DataController` provides two optional properties: `root` and `trim`. Other properties of this object are specified by various editor features.

I hope above makes sense and is understandable for users which are not familiar with CKE5 internals.

@Reinmar
Copy link
Member

Reinmar commented Aug 7, 2020

Quoting myself:

I think that having one object would be best. For example, an option like options.trim also makes sense to be available during conversion. From the integrator's perspective, one will not be able to understand why showSuggestions is a conversion option and trim is not. This is an implementation detail that should be abstracted.

That's why one options object should be enough.

So, I think we agree with each other @scofalik.

@@ -76,5 +76,6 @@ export default DataApiMixin;
* @param {String} [options.trim='empty'] Whether returned data should be trimmed. This option is set to `'empty'` by default,
* which means that whenever editor content is considered empty, an empty string is returned. To turn off trimming
* use `'none'`. In such cases exact content will be returned (for example `'<p>&nbsp;</p>'` for an empty editor).
* @param {Object} [options.conversionOptions] Additional, custom configuration passed to the conversion process.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is no longer valid.

@@ -146,15 +146,16 @@ export default class DataController {
* Returns the model's data converted by downcast dispatchers attached to {@link #downcastDispatcher} and
* formatted by the {@link #processor data processor}.
*
* @param {Object} [options]
* @param {Object} [options] Additional configuration for the retrieved data. `DataController` provides two optional
* properties: `root` and `trim`. Other properties of this object are specified by various editor features.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rootName

@@ -220,6 +224,9 @@ export default class DataController {

this.mapper.bindElements( modelElementOrFragment, viewDocumentFragment );

// Make additional options available during conversion process through conversionSpi.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// Make additional options available during conversion process through conversionSpi.
// Make additional options available during conversion process through `conversionApi`.

@@ -233,6 +240,9 @@ export default class DataController {
}
}

// Remove options from conversionApi.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// Remove options from conversionApi.
// Clean `conversionApi`.

@@ -166,6 +165,7 @@ export default class DowncastDispatcher {
* @fires attribute
* @param {module:engine/model/range~Range} range The inserted range.
* @param {module:engine/view/downcastwriter~DowncastWriter} writer The view writer that should be used to modify the view document.
* {module:engine/conversion/downcastdispatcher~DowncastConversionApi conversion api}. Used only with `dataDowncast` group.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

?

@@ -319,6 +319,7 @@ export default class DowncastDispatcher {
* @param {String} markerName Marker name.
* @param {module:engine/model/range~Range} markerRange Marker range.
* @param {module:engine/view/downcastwriter~DowncastWriter} writer View writer that should be used to modify view document.
* {module:engine/conversion/downcastdispatcher~DowncastConversionApi conversion api}. Used only with `dataDowncast` group.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

?

@@ -71,7 +71,8 @@ export default DataApiMixin;
* the right format for you.
*
* @method #getData
* @param {Object} [options]
* @param {Object} [options] Additional configuration for the retrieved data. By default two optional
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about ...

Additional configuration for the retrieved data. Editor features may introduce more configuration options that can be set through this parameter.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'd leave DataController description as it is now. editor.getData() is a very top-level method, its description needs to be as simple as it can.

@scofalik scofalik requested review from Reinmar and removed request for Reinmar August 10, 2020 12:12
@scofalik scofalik merged commit 0a5d07e into master Aug 10, 2020
@scofalik scofalik deleted the t/7628 branch August 10, 2020 12:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add options to getData() and DataController#get()
3 participants