How to check if editor has no content/is empty?

[oskarwrobel]

In most of cases editor will have an empty paragraph on init. So getData() == '' will be false almost all the time. What if someone adds some spaces or new lines?
For example, you use CKE as an input to write posts or comments and you want to prevent user from submitting form until content.trim() == ''. How to do it?

My first thought was to add an option getData( { trim: true } ) or create method isEmpty( document ) but @pjasiun and @scofalik pointed out that it won't be so easy because there is no common rule for every feature that defines when feature is empty. Eg. Can table be empty? or image?

[fredck]

This is an important feature. In v4 we simply discard the data on output if it looks like empty.

@mlewand, can you point us to this piece of code in v4?

[mlewand]

There's this config option called ignoreEmptyParagraph.

When calling editor's getData() it will perform a regexp replace of empty paragraph (or some other elements based on regexp).

As for content that's true that some elements might be recognized as part of empty content, e.g. empty paragraph, div, section etc. However IMHO having an empty table should not mark editor as empty.

[fredck]

Thanks, @mlewand!

I propose to KISS on this and have an approach similar to v4 at data output processing. I would not make it configurable for now.

[Reinmar]

I really don't like that regexp solution (and most regexp solutions :P). Besides, it would need to be implemented in HtmlDP, because only it works with HTML strings. So, we may need a similar solution for the MarkdownDP later on (e.g. to not print empty list items) and for any other DP.

So, first we need to answer whether this is HTML related feature and can be implemented in HtmlDP because it doesn't concern other formats. Or that it's a generic feature and is required for all formats.

The other question is whether we may need to make it in any way adjustable in the future. We could, perhaps, base this on simple schema checks (checking whether elements are blocks and if so ignoring them if empty). If someone would need to filter out more empty content, then they could do this based on their own checks (you can always have your own isEmpty( doc ) function). However, if we hardcode any solution in getData(), we risk that someone will not want to have some data filtered out. In such case, we'll have a problem.

The last argument means that having a separate isEmpty() method would be better. getData() should have a single responsibility – returning data. Checking whether the data is empty should be another method's responsibility.

[scofalik]

My 2c: right now we could do this using view, but it won't be 100% accurate (I mean, it depends on what we will want to achieve).

In view, we have several different element types, but only two of them are "real" data: Text node and EmptyElement node (used by image). Then we have "containers": ContainerElement (and all child classes) and AttributeElement. Then we have UIElement for UI stuff.

Other idea proposed by @pjasiun was to enhance schema with possibility to mark which elements are data and which are storing data. In other words, which elements should be treated as empty if they have no content.

For example, image is always a content, no matter if it is empty or not. Paragraph is empty if it does not have content. But table is more complicated, maybe it should not be treated as empty even if it is.

[fredck]

We have two options:

1. Make this in 3 lines of code and little talk directly in the HTML DP. Other DPs would have to handle this by themselves.
2. Make this a long discussion, dozens of lines of code, several days of development and review. It'll be perfect, for the sake of being perfect.

I'm definitely for option 1, which can at any moment by replaced by 2, if 1 will be revealed to be inefficient.

That's my point on KISS.

[mlewand]

The last argument means that having a separate isEmpty() method would be better. getData() should have a single responsibility – returning data. Checking whether the data is empty should be another method's responsibility.

+1 it makes a lot of sense

For example, image is always a content, no matter if it is empty or not. Paragraph is empty if it does not have content. But table is more complicated, maybe it should not be treated as empty even if it is.

Keep in mind that you also want to check for number of such "empty elements" as 2 paragraphs should not be identified as empty content.

[fredck]

The last argument means that having a separate isEmpty() method would be better. getData() should have a single responsibility – returning data. Checking whether the data is empty should be another method's responsibility.
+1 it makes a lot of sense

I would look what this issue reporter expected. This may drive the expectation of other developers. If they look to an empty editor, they expect that editor to be empty. By not doing this with getData() (which internally may call isEmpty()), we add yet another level of complexity to implementers trying to use our already complex API.

[fredck]

Also, keep in mind that such checks are many times done at the server side, once data is posted.

[Reinmar]

I'm definitely for option 1, which can at any moment by replaced by 2, if 1 will be revealed to be inefficient.

We won't be able to change this once developers rely on it. And if we plan to make such a non-BC changes it, then there's no point in making them in the first place. We were meant to have a quite stable API after 1.0, weren't we?

we add yet another level of complexity to implementers trying to use our already complex API.

An isEmpty() method is what you actually look for if you want to check if editor is empty. I remember couple of questions on SO regarding this – turns out using getData() isn't that intuitive. See e.g. http://stackoverflow.com/questions/3277250/how-to-check-whether-ckeditor-has-some-text-in-it

It's actually quite depressing because they proposed getting a raw text from the editor and it's the most popular answer there ;|. The right answer is 3x less popular.

An SRP rule tells us that a single method should do one thing. This is KISS. Moreover, it lets you compose the methods differently. If the default isEmpty() implementation doesn't satisfy you, you use another one, but getData() is still ok for you.

E.g., I'd KISS regarding isEmpty(). There's no need to make it configurable through the schema. Since we made it a separate method, if you require different rules, you implement your own method. But you don't need to reimplement the whole getData().

[fredck]

Then go around explaining that isEmpty() == true and getData() is not empty :/

[Reinmar]

As we can see, you need to explain how to check if the editor is empty in CKE4's case too. I, personally, believe that a more explicit API is more verbose. As a result, the system is less magical and less confusing.

I guess we can continue this discussion, but I'd like to hear an opinion of people less accustomed to CKE4. After all, this is not for us.

[Reinmar]

Definition – we call an editor empty if it contains an empty paragraph, list item, heading or another kind of flow element. No text, no images, not sure about tables or other rich content like e.g. simplebox widget.

Pick one:

1. When the editor is empty getData() should return an empty string.
   • Rationale – it allows checking if the editor contains no content just by checking if returned data is an empty string.
2. When the editor is empty getData() should return the data as it is (e.g. <h2></h2>) and developer should be able to check if the editor is empty using a separate isEmpty() method.
   • Rationale – having separate getData() and isEmpty() applies single responsibility principle and lets you e.g. to use a different logic for "is empty".

Note: Consider the fact that definition of the empty editor is not definitive. It's our current assumption and may differ per case.

[scofalik]

I'd go with second because first option gives us nothing and isEmpty() implemented like this will almost always return false, cause we almost always have <p> element there.

Additionally, I'd consider naming the method hasNoContent() to make it more explicit. Also I think this should be Editor method (duh) and specific implementations should be able to overwrite it (if your editor has some weird condition where it is considered that there is no content in it).

Edit: I mean, above is pretty obvious, but what I want to highlight is a fact that specific implementation may have it's own rules and we should treat "default content" or "no content" as something "configurable" and solution-specific.