Feature Proposal: Making Formfields WYSIWYG capable
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
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:
- 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;
hash overrides the behaviour.
I propose for post-Foswiki 1.1 that we move this call to
and make it the caller's responsibility to do the call rather than using the
On IRC I have discussed this change extensively with existing Foswiki developers and nobody thinks it's a bad idea. As
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
Create a new field type:
So rather than hijack textarea elements, I propose we create a new DataForms
. It would override do these things:
- Don't mangle newlines
- In Foswiki 1.1 (and 1.0?) scope, adjust
%attr hash to override
protectFormFieldValue() default behaviour which mangles newlines
- Post-Foswiki 1.1 scope, don't bother calling
protectFormFieldValue() at all
- Fully render the formfield value to HTML
- Strip newlines
- 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
- Output the formfield in a specially marked up
<textarea> to enable a jQuery plugin to hijack any desired editor with appropriate configuration
- 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?
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
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
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...
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
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
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:
-- Contributors: MartinCleaver
- 30 Dec 2008, -- PaulHarvey
- 27 Mar 2010
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.
- 31 Dec 2009
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
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.
- 03 Jan 2010
I see two proposals here:
- Make it possible to use TML markup in form fields
- 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.
- 03 Jan 2010
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
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.
- 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.
- 06 Jan 2010
I have an implementation of this. See Tasks.Item8032
- 03 Feb 2010
at this point, I'm intending to try:
- use jquery plugin to avoid initializing tiny_mce instances that are not used
TINYMCEPLUGIN_INIT_TOPIC to take a list of topics or use topic sections
- ensure that fields are consistently saved as either html or tml, and that any conversions are safe enough
- add datafield definition trigger for wysiwyg. (either new
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
- 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.
- 09 Jun 2012 - 17:11
formfield type initially as a plugin
- 18 Jun 2012
unraveling plugin, as things are becoming pointlessly trivial.
- 20 Jun 2012
What's the status of this? There are lots of checkins recorded at Tasks.Item8082
. Is it done?
- 24 Apr 2013
No answer for another year of inactivity. Deferred to 2.0.
- 02 Jun 2014
Changing to Parked. Needs a developer to adopt.
- 19 Nov 2015