7 Replies Latest reply on Jul 22, 2011 7:52 AM by Lukáš Fryč

    WYSIWYG Editor - Requirements Gathering

    Lukáš Fryč Master

      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)
        • 1. Re: WYSIWYG Editor - Requirements Gathering
          Lukáš Fryč Master

          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).

          • 2. Re: WYSIWYG Editor - Requirements Gathering
            Jay Balunas Master
            • 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
            • 3. Re: WYSIWYG Editor - Requirements Gathering
              Jay Balunas Master
              • 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.

              • 4. Re: WYSIWYG Editor - Requirements Gathering
                Lukáš Fryč Master

                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.

                • 5. Re: WYSIWYG Editor - Requirements Gathering
                  Lukáš Fryč Master

                  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.

                  • 6. Re: WYSIWYG Editor - Requirements Gathering
                    Lukáš Fryč Master

                    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

                     

                     

                    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