Read content from a textarea?

[acasademont]

The textarea sync works nicely, but I have one problem and I'm not sure if we can find a workaround.

Let's say user X edits the description of a product, the form textarea will be synched and the content will be saved to the database when the user submits the form, great!

Now let's say user Y also wants to edit that product description so he opens the edit page in another browser in another machine, hence his localStorage object is empty. Fortunately, as the content was previously saved in the database, the textarea is populated with the last edit from user X but it seems that the textarea content is not read when loading the editor, only the localStorage object. In consequence, user Y sees a blank editor that syncs with the textarea and erases all the previous content without poor user Y noticing anything.

I am missing something? Thanks!

[acasademont]

As a side note, I have also tried to disable clientSideStorage but the textarea seems to be only written, never read. If you find it convenient maybe I can make a patch for this.

[OscarGodson]

I see. Are you using defaultContent? Just tested it and I see how this would be a problem. Downstream changes wont make it upstream because there's content in the localStorage which takes precedence. Here's a "workaround" (but this is actually what I would do even without this bug):

http://jsbin.com/okivow/2/edit

This is a hard problem I think. I'm not sure how to handle this exactly. Let me think about this. This is why it's still in develop tho and not the release, thankfully :)

[OscarGodson]

@acasademont oh, and if you have any suggestions let me know. Pull requests are welcome.

[acasademont]

Yeah, i have a workaround in place, which is to import into the editor the original contents of the textarea after it has been loaded

    $('textarea').each(function(i) {
        var id = this.id,
            value = this.value
        $(this).hide();
        opts.container = id + '_editor';
        opts.textarea = this;
        var editor = new EpicEditor(opts).load().importFile(null, value);
    });

But as you said, this is a workaround, as work is done twice, first to load the editor with the localStorage contents and then we overwrite all this reading work with the importFile.

And in a more philosophical point of view...shouldn't all the epiceditor be centered around traditional forms? Maybe I am totally wrong but I would expect the editor to enhance my already existing and boring textarea with all the nice stuff of previewing the result and fullscreen. And maybe this is related to #100 , why have an iframe for editing? If we had a boring textarea just for editing, HTML could never be pasted in there and that ticket would be automatically solved.

Maybe a SimpleEpicEditor without localStorage and only capablo of enhancing existing textareas could be an option.

[OscarGodson]

All WYSIWYGs are iframes including the most popular, TinyMCE. You can't do anything special with a textarea. There's a lot of neat things we have planned once all the bugs are worked out such as Mou style editing and Byword style context menus on highlight. Can't do that with a textarea.

In hindsight, yeah, EpicEditor should have been made to replace textareas. I made EE for me and my use case and it took off. It was just code I was sharing that people ended up wanting. My use case was web apps. I needed to make an Ajax call to save the contents. I never needed a textarea. You never know how people will use your stuff :)

[OscarGodson]

Also remember that this is the develop branch not the release so expect bugs and work arounds. If you have any suggestions on how defaultContent should work in this case let me know.

[acasademont]

Fair enough! For the time being we're going to stick with a very simple custom solution + marked for the preview, much like Github does with it's comments box. I am tired of the product guys copy/paste from Word & Excel and those "funny" styles applied everywhere, so html filtering is the top priority for us now and for the moment (I'll keep an eye on #100) It seems that sticking to the textarea is the only way of filtering it. The fullscreen option of EpicEditor is just amazing so I'll may end up forking the code for a simpler version of the editor. Thanks for your time Oscar :)

[OscarGodson]

EpicEditor Lite would be a great idea :)

Wont a textarea still show weird unicode characters in the textarea tho? Or is it just the HTML you're worried about?

[acasademont]

mmm not that I know, a textarea should be able to display any character in the browser current character encoding. But yes, I am primarily concerned with HTML since in spanish/catalan there should be no weird chars a part from ñçàáèéíòóu, which display correctly.

[VendanAndrews]

This may be the wrong thing, but I quite easily fixed the textarea handling for my use case(preloaded textarea tag that's altered and resubmited) by changing

self._textareaElement.value = self.exportFile(textareaFileName, 'text', true);

in the textarea handling code to

self.importFile(textareaFileName, self._textareaElement.value);

[OscarGodson]

Do the tests pass @VendanAndrews?

[OscarGodson]

@VendanAndrews your fix broke a lot of tests and caused issues when autosave was set to false. However, your fix gave me an idea. @acasademont I'd love to hear your input. I've updated the code in the feature/ticket-212 branch / commit 49d21bf.

So, what I've decided to do is if there's content in the textarea on page load or when the JS loads use that as the initial content. If, as the developer, you wanted to catch a possible issue where the user's changes are newer than the server you'd just check the modified date of the localStorage file and NOT write to the textarea.

See the big code comment:
49d21bf#L2R942-L2957

This will be merged in when I write some tests for this use case, so if either of you two guys see any issues with this please let me know ASAP! Thanks you guys!

[acasademont]

Hi Oscar! I think this is exactly the expected behaviour, nice!

[VendanAndrews]

tbh, didn't run any tests, just know that that made it pass my tests, sorry :)

Not sure about updating quite yet, as it's all working perfectly and I have it live currently

[OscarGodson]

@VendanAndrews just be careful :) it was completely preventing me from typing in some cases.

But, I don't want you to update–you couldn't anyway because it's in another branch–I wanted to know if the interaction in my code comment sounds correct.

[OscarGodson]

@acasademont @VendanAndrews This is now finished and in develop with tests (ran the tests in IE9, 10, Firefox and Chrome). Let me know if you try this and have any issues with it!