1 2 Previous Next 22 Replies Latest reply on Nov 26, 2008 12:22 PM by Kerdudou Ronan Go to original post
      • 15. Re: Future xHTML Editor (wysiwyg)
        Nick Belaevski Master

         

        "jbalunas@redhat.com" wrote:

        The plan afaik for the inlinepopups is the modalpanel.


        We're not planning to re-implement editor's dialogs using modal panels for now. That is to save us development efforts. This plugin: http://wiki.moxiecode.com/index.php/TinyMCE:Plugins/inlinepopups will be switched on by default.

        "jbalunas@redhat.com" wrote:

        Yes two editors on the same page should be supported. The editors will have default values for many of the parameters - if you want different values for different editors you would need to specify them.


        Sure.

        "jbalunas@redhat.com" wrote:

        I really like the idea of specifying your own default values! We should add that to the tag - Ilya, Nick - what do you thing?


        I would rather suggest to develop several widely-used configurations (e.g. fully-loaded, minimal formatting, extended formatting etc.) and switch between them using attributes. Developer can create his own set of defauts using Facelets templating capabilities then.


        • 16. Re: Future xHTML Editor (wysiwyg)
          Nick Belaevski Master

           

          "RonanKER" wrote:
          on "FuncSpec-RF-CL-E-050-1.2 Editor Skinnability"
          I don't know exactly how you want to do this... as the editor is in an iframe it uses its own css, we can specify other css directory, for ex:"RF", and then inside have the original css modified with RF skinability...
          but for exemple, in my own application, i've got 2 extra css file, one xcss generated css and one default css.
          In my integration of tinyMCE, to be able to have a real WYSIWYG editor, i had to modify its css to include some lines of my general css files...
          So, i need either a way of adding css file to tinyMCE, or perhaps you can make tinyMCE include the css of the page inside its iframe...


          This item is about skinning all TinyMCE elements (buttons, dialogs, etc.) according to our common look, but this definitely needs to be expanded to define how user-provided CSS classes will work. I like the idea of page CSS inclusion.
          Ilya what do you think?

          "RonanKER" wrote:
          Ask me if you don't understand something i've writen :-)

          Thanks in advance for all your work :-)
          Thank you for helping to make the thing better :) !

          • 17. Re: Future xHTML Editor (wysiwyg)
            Kerdudou Ronan Apprentice

             

            "nbelaevski" wrote:
            "jbalunas@redhat.com" wrote:
            I really like the idea of specifying your own default values! We should add that to the tag - Ilya, Nick - what do you thing?
            I would rather suggest to develop several widely-used configurations (e.g. fully-loaded, minimal formatting, extended formatting etc.)
            and switch between them using attributes. Developer can create his own set of defauts using Facelets templating capabilities then.
            of course when using facelets, it's easy to do this, but when we don't use facelets, it's not so easy.

            providing some ready to use config may be a good idea, but most of the time there is so much customisation possible and so much people using it,
            that people might want something slightly different than the provided ones...

            imagine that the tag propose the attibute "config" with proposed values : "normal" (default), "light", "full"...
            will it be possible to make this tag accept personalised values like "custom"
            where the definition of "custom" is somewhere like for exemple in web.xml a param that indicate a link between "custom" and the file where it's defined ?



            • 18. Re: Future xHTML Editor (wysiwyg)
              Nick Belaevski Master

              Ronan,

              I personally do not like the idea of introducing custom file formats. Can you please provide some more information on how this file will look like? What configuration details will be defined there?

              • 19. Re: Future xHTML Editor (wysiwyg)
                Kerdudou Ronan Apprentice

                I don't really know what would i put in this file...
                what's diffcult is to imagine something that can be open for several types of editor...
                i supose the file can contain something readable by an interface but it's quite difficult.

                first possibility:
                the few information that should contain this file is config data for the editor.
                we may have one info on the target editor to assert the use of the file (actually with only one editor possible, it won't be useful but it's for later).
                The others infos would be direct editor config.
                but RF need some base config to make the editor work, so we must treat the fusion of base config and user config...


                second possibility:
                just component config... can be in xml, or just a simple properties file like :

                #Config File for Editor component
                
                #general config (tag):
                type=TinyMCE
                containerClass=wysiwyg
                statusLine=visible
                editOnClick=false
                
                #specific config (f:param):
                mode=advanced
                plugins=fullscreen,inlinepopups,paste
                theme_advanced_buttons1=fontselect,fontsizeselect,bold,italic,underline,separator,justifyleft,justifycenter,justifyright,separator,forecolor,backcolor,separator,removeformat,separator,help
                theme_advanced_buttons2=cut,copy,paste,separator,bullist,numlist,separator,outdent,indent,separator,undo,redo,separator,link,unlink
                theme_advanced_buttons3=
                custom_undo_redo_levels=20
                convert_urls=false
                gecko_spellcheck=true
                paste_strip_class_attributes=mso
                setup=function(ed) { ed.onChange.add(function(ed, l) { doSomething(ed, l); }); }

                it will be interpreted just like if we add <f:param name="key" value="value"/> to the component...
                for the last line of my exemple, regarding your spec, it would become "setup=preprocess"



                • 20. Re: Future xHTML Editor (wysiwyg)
                  Kerdudou Ronan Apprentice

                  in the two cases the component that interface 'TinyMCE' with 'Editor' will have to be able to understand all possible config... and its own config.

                  if someone adds "dialog_type=popup" but Editor by default adds "dialog_type=modal" (config for "inlinepopup" plugin)
                  we have to choose if the user can replace the param or not.
                  but never append it because "dialog_type=modal,popup" won't be accepted by the plugin.

                  however for some other params, like "plugins=fullscreen,inlinepopups,paste" we have to merge with Editor "base config" but not "default config".

                  exemple :
                  base config : "plugins=richface,inlinepopups"
                  default config : "plugins=fullscreen,paste" -> "plugins=richface,inlinepopups,fullscreen,paste"
                  other config : "plugins=table,contextmenu,paste" -> "plugins=richface,inlinepopups,table,contextmenu,paste"

                  items in the "base config" should be minimum, as we can't override them.

                  i think "minimal" config will correspond to "base config" with just a simple toolbar more,
                  other config proposed : "default" (useful tools) and "full" (all tools) inspired from demos in tinyMCE webSite.

                  thoses config can also be stocked in properties file... like it's done for "*.skin.properties", some files are defined in richFaces, and the user can add new files in the classpath...

                  then, we no longer need to define a link to the file in web.xml, but we could define there a param "org.richfaces.EDITOR_DEFAULT_CONFIG" like it is for "org.richfaces.SKIN"
                  this is optional.

                  in the Editor component we can use the attibute "config" with proposed values : "normal" (default), "light", "full"... and the other customs "custom1", "custom2", "tableEditor", "#{context.user.editorConfig}" ...

                  • 22. Re: Future xHTML Editor (wysiwyg)
                    Kerdudou Ronan Apprentice

                    I've just seen this other post on the subject : http://www.jboss.com/index.html?module=bb&op=viewtopic&t=143921
                    so i put a link in this topic for other interested readers...

                    1 2 Previous Next