WYSIWYG Editor - Requirements Gathering

[lfryc]

Before we start to implement editor component, we would like to garther all requirements which are placed on the editor integration into JSF eco-system.

This is the requirement gartherings post instead of full specification, so don't hesitate to bring your ideas!

Events API

• all of the actions should be exposed externally as JSF behaviors may react on them

<rich:editor value="#{bean.editorValue}">
     <!-- autosave -->
     <a4j:ajax event="change" />
          <a4j:attachQueue delay="30000" />
     </a4j:ajax>

     <a4j:ajax event="save" action="#{bean.save}" />
</rich:editor>

JavaScript API

• component exposes API for triggering actions on editor itself

#{rich:component('editor')}.save()

<rich:componentControl event="click" target="editor" operation="save" />

Popups Customization

• most of the editor implementations bundles own modal panels for attaching files, setting options, etc.
• provide events and callbacks to allow reimplementing them

Editor Settings

• theme attribute - for simple/advanced look
• configuration attribute - pointing to configuration file - more detailed settings

Alternative formats

• align requirements with Seam 3
• use JSF converters to convert to alternative formats, no proprietary attributes (like useSeamText)

Skinning

• editor skin (including modal panels) should fit to the RichFaces skinning

Mobile Support

• test usability of particular editor implementations on mobile devices

Optimizations

• editor resources will be compressed and will be possible to merge them into single files per type (CSS, JavaScript, images)

[lfryc]

Mobile Support

• test usability of particular editor implementations on mobile devices

Regrettably no one from suggested implementations are able to handle mobile support.

I propose to detect support and rather use styled textarea (do not download rich editor resources at all).

[jbalunas]

• I like the event api suggestion!
  • It will be important to define all of them
• I want to make sure we isolate the internal editor implementation as much as possible
  • Will make future changes easier ( even if we have to swap the editor )
• I like the JavaScript API as well
  • Again we'll need to make sure to define them
  • Would this include setting options, editing text, formatting?
• Popups
  • Can you describe this more - what is it you mean here?
  • I get concerned about external implementations for uploading files - what options do you see around that?
• Editor settings
  • I want to be careful not target too much for first impl.
  • imo lets get an initial basic/advanced option in first
    • Unless this turns out to be very easy

[jbalunas]

• Alternative formats
  • First implementation should have the possibility of using converters to swap format
    • We don't have to "bundle" different formats for first impl
    • i.e. I want it plugable, but we don't have to provide an alternative
  • With Rf 3 & Seam 2 we actually got into situations with circular dependencies
    • We needed Seam 2 for seam text, and seam needed RF for examples etc..
    • Just something to think about
• Skinning
  • Yup, and we need to check that what ever editor we go with has good support here.
  • Iirc, this turned out to be one of the bigger issues with TinyMCE it was hard to skin and update
• Mobile support
  • Research
    • We should all take a look around and see if there are any rich editors that are being used with mobile devices.
    • On phones I could see size issues for sure, but for tablets I'm wondering if there is something out there
  • Alternatives
    • The only problem with using a text area ( although that is likely the best option ) is that in some use cases that will not be enough
    • If there is not alternative though this will be ok
• Optimization
  • Agree here - it is also related to existing jira on resource optimization.

Lukas - have you looked through existing jira's for issues, usecases, feature requests for the editor?  This might help to flush this out more.

[lfryc]

Jay Balunas wrote:

• I like the JavaScript API as well
  • Would this include setting options, editing text, formatting?

Need to narrow this API down, but generally yes, I would like to give user as much as control over editor as possible. But in scope of 4.1 we would need to cover basics first.

Jay Balunas wrote:

• Popups
  • Can you describe this more - what is it you mean here?
  • I get concerned about external implementations for uploading files - what options do you see around that?

Buttons which opens editor-specific popup panel will raise event and user can cancel default processing and handle event at own - e.g. you can write custom popup panel with rich:fileUpload, and implement callback function (or return method) which will give editor the URL of uploaded image from context of web application.

[lfryc]

Jay Balunas wrote:

• Alternative formats
  • First implementation should have the possibility of using converters to swap format
    • We don't have to "bundle" different formats for first impl
    • i.e. I want it plugable, but we don't have to provide an alternative

I think we don't need built-in converters at all, just document how could be such converters defined and provide samples.

Jay Balunas wrote:

Lukas - have you looked through existing jira's for issues, usecases, feature requests for the editor?  This might help to flush this out more.

I have looked through existing JIRAs, rich:editor proposals for 3.x and also some of discussions in development space - all of that reflected here.

[lfryc]

Summary of my inspections of forums and issue tracker:

3.3.x Docs

Attributes

• width
• height
• value
• theme = {advanced, simple}
• skin
• viewMode
• configuration
• plugins
• readonly
• autoResize ?
• tabindex
• language

Client-Side Events

• onchange
• oninit
• onsave
• onsetup

Dev Forums

Links

• rich:editor component
  • http://community.jboss.org/wiki/RicheditorComponent#comment-1141

Community Forums

Requirements

• get editor instance in JS
• save/print functions
• styling (from dev guide docs)
• direction={ltr,rtl}
• set a caret position to the end after rerender
• selection handling + JS API
• default forn redefinition
• d&d into editor
• hiding editor toolbar
• print to PDF/Word
• spellchecker
• file upload to insert images
• table management
• autosave
• scroll to bottom
• rich:messages
• rich:hotkey does not work from focused rich:editor
• modalPanel
• inplace editor
• customize toolbar buttions

Docs

• h:outputText escape=false
• safety - seamtext alternative = @WebSafe

Personal Concerns

• Client-Side Validation

[lfryc]

Proposal for editor development created at http://community.jboss.org/wiki/RF4Editor