Feature Proposal: Making Formfields WYSIWYG capable

Motivation

WYSIWYG is accepted as a must-have feature for every wiki nowadays.

However, Foswiki doesn't do WYSIWYG in form fields and doesn't even render TML properly when stored in form fields.

This makes the experience of form fields inconsistent with the rest of Foswiki. Data forms are a key differentiator of Foswiki from its competitors. Without wysiwyg in the forms this key differentiator is incomplete.

Description and Documentation

MartinCleaver 's work

MartinCleaver has done an extensive analysis on the issues in Tasks.Item8032, which talks through what he saw as the steps that would need to be followed:

• 1 Meta form fields need to be edited with the WYSIWYG Javascript editor
  • 1b TML newlines would need storing as x0dx0a for fields because Textareas are different to topic texts
• 2. The form fields would need to be not ignored by TranslateHTML2TML 's "don't process meta"*
• 3. TML in form fields would need to be rendered properly on display, AND render of x0dx0a as newlines
  • 3b render TML x0dx0a as newlines

Form API change

The interesting problem is newline encoding; Foswiki::Render::protectFormFieldValue() is always called by Foswiki::Form::renderForDisplay() unless the %attr hash overrides the behaviour.

I propose for post-Foswiki 1.1 that we move this call to protectFormFieldValue() out of renderForDisplay() and make it the caller's responsibility to do the call rather than using the %attr hash.

On IRC I have discussed this change extensively with existing Foswiki developers and nobody thinks it's a bad idea. As Foswiki::Form is not a "public" API we probably don't even need to talk about this change in the proposal. What I did want to change was FormattedSearch reliance on this "broken" behaviour when expanding textareas with $formfield().

Create a new field type: richtext

So rather than hijack textarea elements, I propose we create a new DataForms field type: richtext. It would override do these things:

1. In Foswiki::Form::Richtext::renderForDisplay()
   1. Don't mangle newlines
      1. In Foswiki 1.1 (and 1.0?) scope, adjust %attr hash to override protectFormFieldValue() default behaviour which mangles newlines
      2. Post-Foswiki 1.1 scope, don't bother calling protectFormFieldValue() at all
   2. Fully render the formfield value to HTML
   3. Strip newlines
   4. Now you can comfortably use $formfield(SomeRichtextField) inside a TML table and expect it to not only avoid breaking generated TML tables or lists, but the TML markup from the formfield should be fully rendered properly as if it were an INCLUDE
2. In Foswiki::Form::Richtext::renderForEdit()
   1. Output the formfield in a specially marked up <textarea> to enable a jQuery plugin to hijack any desired editor with appropriate configuration

To-do

• Decide on what can be configured by the DataForms user of the richtextfield type, and how
  • Select allowed editors?
  • Select default editor? (hint: raw edit should still be a valid choice for end users doing data entry)
  • How to implement customisable toolbars, etc. for each editor in a practical way?
• Skin integration issues
  • Full-screen modes need a cross-editor, cross-skin way to add default/universal controls as well as editor-specific toolbar buttons (eg. notification area, "exit fullscreen" link, save/cancel buttons)
  • Double-click-to-edit, in-line editing option from view screen?

jQuery wysiwyg EditorAPI

This is yet to be though through, still brainstorming this.

Need the "ajax" stuff talking to WysiwygPlugin to make it aware of what editor it is talking to, and what options are in effect that may influence the HTML2TML /TML2HTML.

The jQuery EditorAPI should allow the user to change editors not just between a default WYSIWYG but also a list of allowed editors for the formfield (assuming that eventually we will have more than just TinyMCE - jwysiwyg for example).

WysiwygPlugin needs to know the editor it's talking to

Multi-editor support demands the TML2HTML and HTML2TML code will need to know what quirks/work-arounds to apply for the editor that's being used, on a per-formfield basis.

This complicates the save handler business as the WysiywgPlugin will need to know more about a formfield than simply whether or not it must apply a HTML2TML translation at all. And in future it would be nice to have the user or wiki app developer specify what may or may not be allowed in the TML: never HTML tables, never any tables, always strip style attributes, etc...

Examples

PaulHarvey has a high priority to work on this from mid-April and make something deliverable around June.

The work will be implemented in a self-contained PleaseFeelFreeToModify WysiwygJQueryPlugin that will implement the richtext DataForms type and a jQuery javascript EditorAPI.

This way the current TinyMCEPlugin can be left alone as a stable product until such time as this work needs to be merged in a future release (post-Foswiki 1.1)

Hopefully this will be a collaborative effort with other WysiwygTaskTeam members

What is less obvious is what to do with WysiwygPlugin; once a path becomes clear, the following proposals will eventually be ready for consideration by the Foswiki Community:

• WysiwygEditorTranslationRequirements
• WysiwygEditorProfiles
• WysiwygContentPolicies

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: MartinCleaver - 30 Dec 2008, -- PaulHarvey - 27 Mar 2010

Discussion

+1 i would love to see this realized, though i don't know what i can add to its implementation. seems like a lot of code to learn and understand. :-/

there should be a much smaller and more streamlined version of the toolbar available for form textarea's.

-- WillNorris - 31 Dec 2009

jwysiwyg is only 7KiB packed (purely barebones rich text editor, no table handling), my goal is to work towards getting jwysiwyg on formfields.

Working on EditorAPI and WysiwygContentPolicies with respect to setting up a sane way to create/modify and use editor/content profiles is central to this. Such profiles would easily allow users and app developers to have their own toolbar layouts and Eg. strictly enforce only TML tables in their topics.

-- PaulHarvey - 03 Jan 2010

I see two proposals here:

1. Make it possible to use TML markup in form fields
2. Once 1 is done, make it WYSIWYG capable.

The first changes the current behavior and thus may lead to compatibility issues. Then, there should be a way (maybe a flag on the field definition) to preserve the current behavior (and make it the default choice).

I'm totally in favor of these proposals, as long as my concern on compatibility is addressed.

-- GilmarSantosJr - 03 Jan 2010

Hi Gilmar,

You're absolutely right. Actually, I hadn't thought of wysiwyg being the default behaviour. EditorAPI indeed talks about new Type and Attribute values to be used in the form field definitions.

I really haven't thought through what should go into formfields. I am tempted to only allow the TML and basic formatting that already works (even just basic italic, bold, links and images is a highly desirable subset).

Going in to this I always assumed TML tables might be too hard (and perhaps lists as well). I plan to do a lot of refactoring of TinyMCEPlugin and WysiwygPlugin to remove some hurdles blocking a nice wysiwyg formfields solution first because from that we should get some usability improvements wrt configuration and content policy stuff.

-- PaulHarvey - 03 Jan 2010

There's no real reason why TML in form fields should be difficult. The main reason for not doing it in the past was the storage model, which encodes characters in form fields in a way that makes them somewhat tricky when searching using regex. This has a knock-on implication for query search as well, which hoists regexes out of the search expression in order to accelerate the search process - again this assumes that there will be no "difficult" syntax in form fields. If we are prepared to compromise - accept that the inclusion of TML in form fields will make them less searchable - then I can't see any other problems.

-- CrawfordCurrie - 06 Jan 2010

I have an implementation of this. See Tasks.Item8032

-- MartinCleaver - 03 Feb 2010

at this point, I'm intending to try:

1. modify the javascript to deal with multiple tinymce configurations - based on cssClass
2. use jquery plugin to avoid initializing tiny_mce instances that are not used
3. change TINYMCEPLUGIN_INIT_TOPIC to take a list of topics or use topic sections
4. ensure that fields are consistently saved as either html or tml, and that any conversions are safe enough
5. add datafield definition trigger for wysiwyg. (either new richtext and richhtml types, or a 'W'ysiwyg attribute for a field

I'll be stealing code from martin's work, and other things that I find to make something that works on trunk this month so if you have ideas or simplifications, please tell me

-- SvenDowideit - 05 Jun 2012

I do prefer a new field type rather than a new attribute. What does it mean to WYSIWYG a checkbox?

I'm unsure what you mean by your change to TINYMCEPLUGIN_INIT_TOPIC. As long as we can separately configure the TINYMCE settings for the topic text vs formfields.

-- PaulHarvey - 09 Jun 2012 - 17:11

adding richtext formfield type initially as a plugin

-- SvenDowideit - 18 Jun 2012

unraveling plugin, as things are becoming pointlessly trivial.

-- SvenDowideit - 20 Jun 2012

What's the status of this? There are lots of checkins recorded at Tasks.Item8082. Is it done?

-- MichaelDaum - 24 Apr 2013

No answer for another year of inactivity. Deferred to 2.0.

-- MichaelDaum - 02 Jun 2014

Changing to Parked. Needs a developer to adopt.

-- GeorgeClark - 19 Nov 2015

Commenting is disabled while not logged in