Using/Configuring the Sakai Rich Text Editor

March 22, 2008

The rich text editor in Sakai has a very hard row to hoe. It needs to be:

  1. invoked in the context of 6 view technologies (Velocity, JSF, SPRING/MVC/JSP, XSLT, RSF, Servlets, am sure am forgetting some!)
  2. configured to run plugins (Sakaibrary, Josh Ryan’s Entity Browser, etc.) or not
  3. stand being poked into a number of curious contexts, fulfilling any number of disparate purposes, from helping people write smallish blurbs, blog entries, full blown web pages, the Encyclopedia Galactica, etc.
  4. display in tight spaces, take over the whole screen, stuff in between…
  5. be any rich text editor – the tool invoking it need not know what rich text editor is being invoked – FCK, HTMLArea, TinyMCE, etc.

This is what it looks like at present (FCKEditor used as example below). This is default, when no parameters are specified it resolves to an editor area 600px wide, 400px tall, with the Default ToolbarSet.

default.png

In the Velocity tools the editor is invoked via a daisy chain of macros and templates. Unfortunately the only parameter that makes to the actual editor script is the id of the textarea being replaced. Am addressing that in SAK-13244.

Sakai tools that use Velocity will have the following in a template:

<textarea name="body" class="block" id="body"
  cols="65" rows="30" wrap="virtual">
</textarea>
 #chef_setupformattedtextarea("body")

The #chef_setupformattedtextarea macro lives in VM_chef_library.vm:

#macro (chef_setupformattedtextarea $textarea_id)
  ## setup wysiwyg editor
  #set($editor_path = "vm/editor/$!sakai_editor/sakai_body.vm")
  <!-- $editor_path -->
  #parse("$editor_path")
  <script type="text/javascript" defer="1">
   chef_setupformattedtextarea('$textarea_id');
  </script>
#end

and essentially uses a server variable ($!sakai_editor) to decide on the rich text editor that the installation is using, then calls a text editor specific template (vastly simplified below) that sets up some configuration values:

function chef_setupformattedtextarea(textarea_id){
  var oFCKeditor = new FCKeditor(textarea_id);
  oFCKeditor.BasePath = "#libraryLink("editor/FCKeditor/")";
  <snip />
  oFCKeditor.Width  = "600" ;
  oFCKeditor.Height = "400" ;
  oFCKeditor.Config['CustomConfigurationsPath']
    = "#libraryLink("editor/FCKeditor/config.js")";
  oFCKeditor.ReplaceTextarea() ;
}

The thing to notice is that the only value passed along the chain is the id of the textarea in the template that will be replaced with the editor. What values would be minimally useful other than that? I decided arbitrarily that width, height and editor toolbar options would be the most useful. I wonder if this is true.

So now the calling template has:

#chef_setupformattedtextareaparams("description" "400"
  "600" "Default")

and the macro in VM_chef_library.vm reads:

#macro (chef_setupformattedtextareaparams $textarea_id
 $height $width $ToolBarSetChoice)
 <snip />
 <script type="text/javascript" defer="1">
   chef_setupformattedtextarea('$textarea_id','$height',
    '$width','$ToolBarSetChoice');
 </script>
#end

Note that there is a new macro involved (chef_setupformattedtextareaparams). The old one (chef_setupformattedtextarea) expects one parameter only. Velocity macros cannot deal with missing parameters, so need 2, one macro that expets one parameter (the id of the textarea) and another that expects exactly four.

The template that drops the javascript onto the the template DOM is would use the paramenters if available and provide some defaults if not.

Height and width are pretty self explanatory, toolbar settings are trickier. FCKEditor allows for named bundles of toolbar functionality – out of the box is provides “Default,” “Attachments,” and “Basic.” To these I have added the following: “large”, “medium” and “small” described below. These names were adopted because they are the same as the ones used in the HTMLArea option. Since a given bundle has certain horizontal needs I indicate the width sweetspots for each.

small

365 px wide or more. This essentially is the FCK “Basic” plus some added functionality. The emphasis is on writing text, without too much block formatting (other than lists), and no non-textual elements. Suitable for comments, quick text entries, snippets of all types.

sakai-min.png

medium

410px wide or more. Is like small + links to word processing like functionality (copy, paste, undo, search) as well as embedding,linking and extended formatting options.
sakai-med.png

large

At 410 it will display 5 rows in the toolbar, at 500px will display 4 and at 600 it will display 3. Essentially the FCK “Default” minus some functionality and rearranged somewhat for more width elasticity.

sakai-max.png

largecompressed

Same set of options as large but toolbar will fit in small areas – 380px wide, for example.

The choices above can be seen as arbitrary. I will try to get feedback on them. Ideally the user could swap between choices, but at the very least we can provide some useful defaults.

Next – invoking and configuring the editor in JSF, as well as the problem of multiple parameter types for some options such as the toolbar options in various editors.

JSF invocation

There are 2 tags available. <sakai:inputRichText /> and <sakai:rich_text_area />.

sakai:inputRichText:

presentation parameters: width, height (integers, in pixels), cols, rows (integers – some conversion to actual height and width takes place in the tag), toolbarButtonRows (integers, or string – in the later case it is a named set of buttons sets: “small”, “medium”,”large” and “largecompressed” )

sakai:rich_text_area:

presentation parameters: width, height (integers – in pixels), cols, rows (integers – some conversion to actual height and width takes place in the tag), buttonSet (string – the values are “small”, “medium”,”large” and “largecompressed”)

Advertisements