8 Replies Latest reply on Nov 25, 2008 9:42 AM by ilya_shaikovsky

    New Component Planning <rich:editor/>

    ilya_shaikovsky

      The RichFaces team is starting to develop a new component that will wrap tineMCE editor widget to JSF component. We wanted to open the discussion to the community and get feedback to our planning documents and ideas for it in one place.

      Below are current plans and open issues. The initial functional spec is http://anonsvn.jboss.org/repos/richfaces/management/design/Editor/ .

      Editor page definition

      Editor component will be represented with <rich:editor/> tag on the pages. It will already provide its own textare as opposite to original widget which could be attached to some areas by selector.

      OPEN ISSUE. Is providing own textarea ok?

      Editor will have two states WYSIWYG representation and just text area representation. Some addition in just text area state are planned. For now it is a status bar with current position or some conversion/validation errors displaying.

      Editor configuration
      We plan to revise the options of original widget and define most popular as a component attributes. All other options will be configurable using next syntax:

      <rich:editor>
       <f:param name="mode" value="advanced"/>
       <f:param name="theme_advanced_buttons1" value="separator, insertdate, inserttime, preview, zoom, separator, forecolor, backcolor"/>
      </rich:editor >
      


      Editor Callbacks

      There we have two options. One of them is similar to configuration way and looks like:

      <script>
       function setup_function(){
      
       }
      </script>
      
      <rich:editor>
       <f:param name="setup" value="setup_function"/>
      </rich:editor>
      

      So in this way ajax calls could be performed in a next way:
      <a4j:jsFunction name="preprocess"/>
      
      <rich:editor>
       <f:param name="setup" value="preprocess"/>
      </rich:editor>
      


      And the second way is to move this callbacks to attributes of the component.

      OPEN ISSUE: Lets final choose the way to implement this.

      Additional Plugins
      Two most popular plugins FileManager and ImageManager also planned to be implemented.

      OPEN ISSUE: Guys lets move this finally to the next release in order to focus on base functionality and provide more stable base component in first release.

      Seam Text Support
      Seam Text support will be available within this component. Initially we has two options to implement this support - client side plugin (as for BBCode exist) or plug the built in converter to the component in order just to convert html to seam text after the result stored with form submit.

      OPEN ISSUE. We finally choosen the second way. If anybody has some opposite opinion feel free for comments.


      This is just our initial high level requirements. Now we're working under prototyping and still free for your opinions about features which should exist within this component.

        • 1. Re: New Component Planning <rich:editor/>
          jbalunas

          I will have further comments, but this forum topic also discusses this, and contains some good information.

          Future xHTML Editor (wysiwyg)

          -Jay

          • 2. Re: New Component Planning <rich:editor/>
            ilya_shaikovsky

            This post will describe how we plan to implement parameters redefinition and configurations for rich:editor.

            1) Attributes
            Most importaint tinyMCE properties and callbacks will be defined as attributes on the component level
            2) Parameters

            <f:param/>
            component should be used in order to define the properties which is not defined with attributes. Name should be defined as some tiny property name and the value should be used in order to set the value of this property.

            3) Configurations
            We plan to introduce
            <rich:editorConfiguration/>
            tag which should be responcible for configurations definition. It should be used in a next way:

            3.1) The user should create some set of propetrty files in the classpath (e.g. tiny_custom_config1.properties, tiny_custom_config2.properties and so on)
            3.2) Define in pairs all needed parameters with their values in the property files .
            3.3) put set of editorConfiguration tags as a child to some editor component with attribute name defined:

            <rich:editor..>
             <rich:editorConfiguration name="tiny_custom_config1"/>
             <rich:editorConfiguration name="tiny_custom_config1"/>
            <rich:editor/>

            3.4) the user should define config to be used in editor currentConfig attribute:

            <rich:editor currentConfiguration="tiny_custom_config1">
             <rich:editorConfiguration name="tiny_custom_config1"/>
             <rich:editorConfiguration name="tiny_custom_config1"/>
            <rich:editor/>


            3.5) The user could define EL binding inside currentConfiguration attribute. So the configuration for the editor becomes managable.

            • 3. Re: New Component Planning <rich:editor/>
              jbalunas

               

              "ilya_shaikovsky" wrote:
              This post will describe how we plan to implement parameters redefinition and configurations for rich:editor.

              1) Attributes
              Most importaint tinyMCE properties and callbacks will be defined as attributes on the component level


              +1 - could you draft a list of those?


              2) Parameters
              <f:param/>
              component should be used in order to define the properties which is not defined with attributes. Name should be defined as some tiny property name and the value should be used in order to set the value of this property.


              +1


              3) Configurations
              We plan to introduce
              <rich:editorConfiguration/>
              tag which should be responcible for configurations definition. It should be used in a next way:

              3.1) The user should create some set of propetrty files in the classpath (e.g. tiny_custom_config1.properties, tiny_custom_config2.properties and so on)

              Can the file be named anything or is the name specific?

              3.3) put set of editorConfiguration tags as a child to some editor component with attribute name defined:

              <rich:editor..>
               <rich:editorConfiguration name="tiny_custom_config1"/>
               <rich:editorConfiguration name="tiny_custom_config1"/>
              <rich:editor/>



              Is this a typo? I'm assuming you mean to have different config files in the above example?


              3.4) the user should define config to be used in editor currentConfig attribute:

              <rich:editor currentConfiguration="tiny_custom_config1">
               <rich:editorConfiguration name="tiny_custom_config1"/>
               <rich:editorConfiguration name="tiny_custom_config1"/>
              <rich:editor/>


              With this approach are the nested editorConfiguration elements even needed? What are they doing for you?


              3.5) The user could define EL binding inside currentConfiguration attribute. So the configuration for the editor becomes managable.


              Good, but do we need to have the editorConfig only work with property files? Could a user define an editor configuration like below:

              <rich:editorConfiguration name="fooConfig">
               <f:param name="" value=""/>
               ......
              </rich:editorConfiguration>
              


              Then reference this configuration using the same approach you meantion above:

              <rich:editor currentConfiguration="fooConfig">
              .....
              <rich:editor/>


              • 4. Re: New Component Planning <rich:editor/>
                ilya_shaikovsky

                I'm afraid that using editorConfiguration as it shown in your snippets (params just as children) - page will be to huge if set of some complex configs should be created. So using your syntax the customer will have to create some page to be included and define the configs there in this case?

                Then anyway additional file should be created and included.

                But in my case configs splitted to the files one for the config and contains only params with values. And I think it's easier to manage them later.

                • 5. Re: New Component Planning <rich:editor/>
                  ilya_shaikovsky

                  Also about separate tag for configuration definition.. Yes.. seems it could be eliminated.

                  • 6. Re: New Component Planning <rich:editor/>
                    pmuir

                    For 3.3, 3.4, 3.5 how about just doing:

                    <rich:editor settings="/rich-editor.properties">


                    Where settings can reference EL. Then we don't need all these extra tags and it's still flexible.

                    • 7. Re: New Component Planning <rich:editor/>
                      ilya_shaikovsky

                      http://www.jboss.org/community/docs/DOC-12943

                      public specification published.

                      • 8. Re: New Component Planning <rich:editor/>
                        ilya_shaikovsky

                        RichFaces 3.3.0.BETA1 has been deployed to: http://repository.jboss.org/maven2/org/richfaces/ui/richfaces-ui/3.3.0.BETA1/

                        So rich:editor available for public review within this BETA.