Form mode

[OscarGodson]

This might be better for an extension, but I've gotten one issue filed and a couple people in person ask how, if this isn't a form element, they'd handle a form. The answer is to serialize their form and use exportFile() and add it to the form serialization, but that is kinda a pain. Instead it'd be cool, built in or not, to simple set "formMode: true" and behind the scenes EpicEditor would sync the content of the conteneditable iframe with a <textarea> that's hidden.

[librarian]

I need this feature. Maybe you could suggest how to implement this feature by myself?

[OscarGodson]

@librarian

It's pretty easy. There's two ways you could do it:

1. Have an invisible (display:none;) textarea that syncs it's content with the editor.
2. On submit, get the content of the editor and post it.

It depends on how you need it. But #1 above would be super easy. Since it's a real form element, on submit it'll just work. Here's an easy way you could implement it: http://jsbin.com/oziboh/edit#javascript,html

[librarian]

Thanks.

[OscarGodson]

Since I've been working with EpicEditor now in real apps I see this is makes things a lot easier especially when prototyping or integrating with existing forms. I'm bumping this up from "extension" to feature and going to try to get this into 0.3.0.

I'm thinking it'll generate a hidden textarea OR you can connect it to an existing textarea. Something like:

// Use textarea you made yourself
var myTextarea = document.getElementById('my-textarea');
var editor = new EpicEditor({ textarea: myTextarea });

// Or, if you pass it some textarea options it'll create a textarea with those attributes and it generates: 
// <textarea style="display:none" name="myTextarea" id="myTextareaId" class="youGetThePoint"></textarea>
var editor = new EpicEditor({
  textarea: {
    name: 'myTextarea'
    id: 'myTextareaId'
    class: 'youGetThePoint'
  }
});

// Or lastly, if you dont pass anything, just the following, it'll generate:
// <textarea style="display:none" name="epiceditor-textarea"></textarea>
var editor = new EpicEditor();

// But, of course, you could force it away with:
var editor = new EpicEditor({textarea: null})

And, EpicEditor will just keep the textarea up to date with the editor's text like my example above.

@johnmdonahue @jensscherbl - How do you guys feel about this?

[jensscherbl]

First example makes sense to me, the others not so much. Editors should only enhance existing (form) elements in an application view, not create crucial parts of it during runtime. Makes it easier to just drop in and swap different editors as needed.

Maybe @tonyarnold has some additional thoughts (he's developing and maintaining a new EpicEditor-extension for Symphony CMS, since I'm experimenting with another approach).

[OscarGodson]

So, do you think @jensscherbl if you don't give it a textarea it should just not create any textarea and basically act as it does now?

[jensscherbl]

I wouldn't overcomplicate things here and instead just require a textarea. Even if developers don't use oldschool form handling in their applications and instead doing everything via JavaScript and XHR, having a textarea in the view as a placeholder for EpicEditor (or any other editor) makes building views easier and more straight forward in my opinion.

[OscarGodson]

@jensscherbl
Hmm, I'll think about it. It makes sense tho, but will it bad breaking change for every EpicEditor instance. I closed the IE7 ticket because I just don't want to support it and requiring a textarea would make it so IE7 falls back to a textarea which is nice.

Drupal put this in their WYSIWYG module and not sure who else has been putting this into major projects, so that's my biggest concern. I'm leaning toward requiring* it (note the *) and not auto-generating one based on your comments.

*The docs will reflect it's required and there will be no examples of the current way, however, if you choose a container that doesn't contain a textarea it'll just ignore that and go along gracefully. It'll just "work" if you don't have a textarea. Actually forcing the script to die if you don't have a textarea would be more code than having it just ignore it anyway.

[tonyarnold]

Hi @jensscherbl & @OscarGodson — I agree with what you guys are talking about here. The editor shouldn't create it's own text areas. I don't really have much to add beyond that, but the logic is that I should be able to switch editors without much effort (and most editors seem to require an existing text area).

[dbrgn]

Please include textarea support :) I agree with @jensscherbl though, a textarea should be required, not created.

[OscarGodson]

@dbrgn yep, this will be in there soon. It'll be the next thing I work on. But as I said above it wont be required since requiring it would actually be more code and more complicated than just adding support for it and wouldn't be backwards compatible and create frivolous markup for people doing Ajax. But I'll try to get this in develop ASAP. Thanks for the support and if you have any suggestions or concerns about this let me know your use case :)

[OscarGodson]

Alrighty. This should now be working. It's in develop and will be in the next release (0.2.1). Please test it and make sure it does what you guys want :)

You can see the docs, but the short is, you now have a textarea option. It's null by default and if you do a string it'll lookup an ID of an element or you can give it an element like document.getElementById('foo'). Once they're linked they will sync exactly what you see in the editor. It updates every 100ms.