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.

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.

"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?

"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 ?

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 :

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

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}" ...