Wysiwyg-editor: A way to get latest HTML even from code view

[philfreo]

• Visit http://jsfiddle.net/9ru3kL5m/
• Type in editor, click button. You see latest HTML is gotten through either method 1 or 2.
• Switch to code view, type something, click button. Latest HTML changes are unavailable via either method 1 or 2.

There should be some simple/consistent way to get the HTML from the editor without making the user toggle back to non-code-view first.

It should show up in $textarea.val(), but I don't mind if I have to call a method first to sync/update the value before I check the .val().

[ConorHiggins]

👍 from me. Have had to use a workaround for this which is potentially confusing to users. I need to lock save/update buttons when the code view is in use unfortunately.

[stefanneculai]

You can use the codeView.get method for that: https://www.froala.com/wysiwyg-editor/docs/methods#codeView.get

[philfreo]

@stefanneculai I don't think that really does what I'm asking.

I shouldn't have to care whether the user is in wysiwyg mode or code mode. At some point they hit "Save" or "Send" or whatever and I need to get the latest editor html/value at that point.

[stefanneculai]

The changes from code view are highly sensitive because users might type HTML that is incorrect and then hit save. We won't make the html.get return the HTML directly from the code view in anyway. That is because we want to make the developers fully aware of that. You could check if the user is in code view using codeView.isActive and get the HTML with codeView.get.

[philfreo]

If the user is in code view and html.get is called then it should return the same as if the user switches back to Edit mode and then I call html.get

[stefanneculai]

Actually not, because html.get is designed to work only with the editor core. Code view is a plugin and the editor is not aware of it, only the plugin is aware of the core. If you want this feature hardly, you could use the html.get event and return the html from the code view.

[philfreo]

Okay, but don't you see how my case of simply wanting to having the following is not super special and should be solved in as few lines of code outside of Froala as possible?

1. Have a Froala editor
2. Have a Save button
3. User expects Save button to save their work

[stefanneculai]

You could add the following event which would return the HTML just the way you want.

$(selector).on('froalaEditor.html.get', function (e, editor) {
  if (editor.codeView.isActive()) {
    return editor.codeView.get();
  }
});

[philfreo]

Didn't you say that would skip the cleaning stage? Basically what I'm saying is that my "step 3" should return the exact same html output regardless for all the following:

1. user is in wysiwyg mode and hits save
2. user is in wysiwyg mode, switching to code view, and hits save
3. user is in code mode and hits save

And I should be able to request this with a simple call into froala.

[stefanneculai]

@philfreo I understand that for you it would be ideal to get all through the html.get method, however we won't make it available this way for the reasons I explained above. If you want to get the code unaltered you can do as in the previous comment. For the code cleaned, you can use the following code inside the callback of the save button to sync the HTML to the textarea on which the editor was initialized.

var editor = $(selector).data('froala.editor');
if (editor.codeView.isActive()) {
  editor.html.set(editor.codeView.get());
  editor.events.trigger('contentChanged', [], true);
}

Then the html is available both when calling html.get and in the value of the textarea the editor was initialized on.

[philfreo]

Thanks, that's helpful and will use that.

I'm _not_ saying necessarily that the html.get method should do this. But what I'm trying to communicate is that I suspect that almost ALL of your users who use the Code plugin will either run into this problem. For many they will have this problem and not realize it but their users will experience bugginess / unsaved data. I'm not saying html.get should be _the_ method, but I'm saying that you should have a single interface for getting the latest/cleaned HTML that handles this under the hood.

[stefanneculai]

The editor is actually doing this by default when it lives inside a textarea and the form is submitted.

[philfreo]

That's smart. Just think you shouldn't make it any harder for people handling their own submissions.

[stefanneculai]

Not documented, but I believe you can also use the following to sync the code with the same outcome.

$(selector).froalaEditor('events.trigger', 'form.submit');

[philfreo]

Thanks, that works great. I'm using this now instead of what you recommended in #1475