…when you have the  Sakai Entity Broker and jQuery in your hand. It is an extremely useful combination that certainly has a place in Sakai 2.x.

At some point, for example, one of us snuck in the FCKEditor for editing a Sakai site description. The problem is, the display locales for the site description were not designed to render gracefully complex/long/enormous/gigantic  blocks of stuff, they were reserving space for the original plain text description only !

One solution is to strip the html and display the first “n” characters (KNL-133).   This solves the problem of the rich text description mangling the context (gateway sites list, site info, etc.).

And yet the original  information in the site description was of importance to the person who crafted it – how to make it available again? Enter the Entity Broker.  Since the context provides the ID of the site the RESTful url to the site’s information is:

‘/direct/site/’ + siteId + ‘.json’;

The rest is a matter of parsing the site JSON, extracting the useful info, and displaying it in (following Noah Botimer’s recommendation) a jQuery UI Dialog. The details can be found at SAK-15861 – the trickiest part was manipulating the dialog to display correctly in an iframed environment, but luckily the jQuery UI Dialog was very tweakable:

We considered other places where this would be useful. One obvious place was in group selection instances. When creating an assignment, targeting an announcement, restricting a resource access, etc.,  you can select what groups are involved.  A modal dialog displaying the group’s membership might be good (“Who is in this ‘The Scroungers’ group after all?”). As with the site description there is a handy url:

‘/direct/membership/group/’ + groupId + ‘.json’;

That can be parsed for useful data which can be displayed in a dialog, this time with the addition of a print preview link that might be helpful.

The combination of the Entity Broker and jQuery makes this absurdly easy, there is no actual, um, development in the traditional sense going on here.   A project we are almost done with at Michigan uses an “entitized”  provider to display to a user a list of the courses they are enrolled in, links to the corresponding site if any, as well as a way to navigate to past and future terms.  This was designed to address the “Where is my course site?” issue that the tab metaphor unfortunately produces as a side effect.

Once the heavy lifting was done entitizing the provider (thanks to Savitha!) the view component was not only fast but fun to produce. We used a velocity template but only to load the language strings into a json, otherwise it could have been just some html.

The urls in this case were, to retrieve the terms that the user was registered for courses:

“/direct/mycourses/terms.json”

This is used to build the navigation menu for the user. The current term and any the user picks is retrieved via:

‘/direct/mycourses/’ + termId + ‘.json’;

The json gets parsed and the UI gets constructed (blurred here because this is an actual person/persons, real CM data):

That is it.  This is happening in these msub  branches: CT-912 mycourses and CT-912 ctools-provider.

There are a few things that need a lot of work. For one, since this is mostly DOM manipulation (all of the information of value here is the result of DOM manipulation) and since it is sort of a central piece of information (what are your courses, where are the sites) it makes it both important and difficult to ensure it is accessible. Will be studying ARIA ways of addressing this.

Sakai has a portal for small devices since 2.4. It is pretty bare bones but it does several neat things:

1. it flattens the tool/site hierarchy so that they can coexist in the same breadcrumb
2. it serves up an iframeless experience
3. it elides many elements from the portal that would be noise in a small screen

Am working on several improvements to it for Sakai 2.7  under SAK-14827 and we are testing it at Michigan. It has been a very instructive experience constraining things to the small screen. What follows is a description of the changes, some tools and techniques that were useful, and some  observations from the preliminary testing.

The main tool turned out to be an iTouch that Chuck Severance donated to the lab. I tried several emulators such as iPhoney, Apple’s iPhone Simulator that comes with the iPhone SDK but there was no substitute for the actual thing.

Initially all I had in mind was polishing the portal, taking into account the screen size and the input device (your finger!). The PDA portal is served via a single Velocity template file present at a specific URL, so there was no need to do device detection – if you are there, you are using  a PDA (or, if you want to use a PDA you should use that URL). In the future it would be nice to route that  user agent to that URL automatically.

http://localhost:8080/portal/pda

The main complication was setting the viewport via the <meta /> tag. The official documentation is very telegraphic, but there is discussion about it. Eventually I settled on the following:

<meta name="viewport" content="width=device-width,
     user-scalable=yes,  initial-scale=1.0, maximum-scale=2.0"/>

The main issue here is font sizing after an portrait/landscape orientation change or after the user input zoom function takes place. Amazing to think that some people are using Javascript to detect the first.

The second task was to take all the styling references out of the template and out of the experimental portalstyles.css and create a CSS framework for the PDA. This entailed adding a pda.css + 3 images to each skin in the system, and querying in the template what was the skin in use per site.

Note: I have only checked into trunk the style sheets and images. The changes to the velocity template (pda.vm) and loginTool.java are being reviewed.

Now that the PDA portal was skinnable, it’s styles could be addressed via the CSS. The main preoccupations here were the following:

1. font sizing
2. adjusting padding/margins on links so that fingers of a moderate fatness could poke in the right place…
3. curtailing horizontal spread

The results for the gateway pages and the site/tool pages are pretty good. Below with the University of Michigan skin, site navigation.

The tool navigation:

And an actual tool:

I have craftily selected a tool for the screen-shot that works very well in this medium: the calendar summary from the excellent folks at Universidade Fernando Pessoa. Other tools are less fortunate.

A fun thing was adding icons for bookmarks. Following this tutorial I created a handful in no time. The iPhone actually takes care of all the glitz effects (corners, glassy look).

And this is what the icon looks like in the “desktop”

And what the Sakai skin looks like:

Preliminary testing with the iTouch indicates some problem areas.

1. Any tool that uses internal iframes is hosed.
2. The browser detection identifies the iTouch as Safari, and serves it the default rich text editor, with it is unable to use – it should instead serve a plain text area.
3. Cannot do attachments because the <input type=”file” /> is disabled in the iTouch.
4. Not all tools render nicely, lots more to be done in this area.

In order to create a skin for a RTL context we will be working in a the tool.css (so that we can override tool_base.css) of a new skin, named RTL. We will identify changes that need to be made, workarounds, failures to account for an RTL context in the tool design, etc.

If you are not very interested in the details  - the uncombed and disreputable skin is availiable here

If you want to know how we got to this and the shortcomings of this approach, read on.

We will begin with a simple tool view  - the Announcements list. What it looks like in a LTR context:

What the direction:rtl applied to .portletBody gets us. Am keeping the language as English.

Some nice things: the toolbar has been rearranged. The columns of the announcement table have been flipped correctly. Block elements are now flush right, such as the <h3>Announcements</h3>. The label of the view navigator select is not to the right of the select. The select itself is reoriented. The list paged lists, from right to left: “first page, previous page, next page, last page” correctly as the entire block has been flipped.

Some things that will need to be addressed: a) the pipes between the toolbar items look wacky and need to be aligned right; 2) the navigation panels need to be flipped ( a sad irony: if the layout of these and the toolbar  had been a table our work would be done); 3) the text direction of the cells inside the table needs to be adjusted.

The toolbar

Align the toolbar right. We will be working in the new rtl/tool.css):

.navIntraTool {
	text-align: right;
}

Add a border to the span child of the first list element:

}
/*special style for the first item, namely no border-left*/
.navIntraTool li.firstToolBarItem span{
	/*border:none;*/border-left:1px solid #ccc;
}

and take the border away from the last:

.navIntraTool li:last-child span{
	border:none
}

Since the design of the toolbar did not take into account a RTL possibility we had to resort to a pseudo class to identify the last element. We will see this problem elsewhere.

The navigation panels

The layout of these is set in tool_base.css. We will override in rtl/tool.css:

.viewNav{
	float: right;
}
.listNav{
	float: left;
}

The table list

/*skinned header of standard tab. data table*/
.listHier th, .listHier td{
	text-align: right !important;
}

The !important is needed to override the !important in tool_base.css - a bad decision that now needs to be dealt with.

The end result:

And in the target language:

Some issues remain with the navigation panels – reversing the floats did not exactly reverse the position, resulting in some inexplicable whitespace.  Someone help, please.

To recapitulate before we take on a more complex view of this tool: a) any series that identifies a first item also needs to identify the last; b) floats are not always totally reversible.

Forms and inputs

Some problems regarding the layout of the input, label and required marker troika. The orientation of the three is just not working due to floats. An example from create a new announcement.

So we rearrange the floats and display attributes, paddings, margins (if you are redoing an existing skin, look for some of these definitions elsewhere in the sheets if your results do not match):

.shorttext label{
	float:none;
	display:block;
	padding:0;
	margin:0;
}
.shorttext .reqStar{
	float:right;
	margin-right:-7px;
}
.longtext label{
	float:none;
	display:block
}
.longtext label .reqStar{
	float:right;
	margin-right:-7px;
}

So:

And in Arabic:

The other input types render correctly without any tweaking (this is also from create a new announcement):

While on the subject of inputs, the following is also needed if there is to be mixed RTL and LTR content:

input, textarea{
	unicode-bidi: override;
}

A quick glance over the core tools and it seems most rendering now is OK. There will be exceptions where the developer has been forced to apply sui generis layout or styles because of the paucity of the default styles. There will also need to be addressed – please leave some comments where that is the case, thanks!

Off hand – here are some locales that need more work because of these and other reasons:

1. Filtering controls in Schedule list view.
2. “Add” menu in Resources – text is misaligned.
3. Certain icons are facing in the wrong direction – such as disclosure triangles. These will need to be replaced in the file system when they are inline images, or in the skin when pulled as background images.
4. The FCK Editor – needs configuration – information on configuring the FCK Editor for RTL is here. There are language files for Arabic and Hebrew, Persian as well. Probably a lot of other stuff that a native speaker could figure out needs to be tweaked.
5. Placement of icons inside certain blocks needs to be tweaked – see alertMessage etc. 

The uncombed and disreputable skin is avaliable here.

Some things we left disheveled in a previous post about the RTL Sakai Portal, I will address these below. We are modifying a pre-existing portal in case this is useful to a context where the LTR and the RTL experiences need to coexist – then you can just modify the existing LTR portal skin. If the context is strictly RTL, you might be better off starting from scratch. I will provide a starter RTL skin at the end.

Site navigation

Some portal clean up: the pipes between site links still reflect a LTR orientation.

Change the location of the borders:

/*links to other sites*/
#siteLinkList a,#siteLinkList a:link,#siteLinkList a:visited{
    color: #fff;
    padding: 2px 6px 2px 4px;
    text-decoration: none;
    /*border-right: 1px solid #fff;*/border-left: 1px solid #fff;
}

and take borders away from the last link (which is the left-most one):

#siteLinkList li:last-child a{
    border:none
}

Portlet titles

The portlet titles also need sorting, flip the floats and text directions :

.portletTitle .title{
	/*float: left;*/float: right;
}
.portletTitle .title a{
	/*float:left;*/float:right;
}
.portletTitle .action{
	/*text-align: right;*/text-align: left;
}

So now the direction is correct:

Presence

Presence also shows the old LRT orientation:

On the portal level – adjust the title:

#presenceTitle{
   font-size: .7em;
   /*text-align: left;*/text-align: right;
   margin-left: .5em;
}

The presence list is inside of an iframe – and as such it is a tool, so it will be a useful segue to RTL’ng the tools. As with the portal we are adding the direction attribute to the first child of body (.portletBody).

.portletBody{
   direction:rtl
}

This will get us a lot of LTR > RTL changes for free in all of the tool descendants as we will see later. Except in the presence list as that doc does not have a .portalBody wrapper!!! Since presence does not have a .portletBody we need to add direction attribute to the list itself and fiddle with the paddings:

/*below for "presence in chat" functionality*/
.presenceList{
   font-size: .8em;
   list-style: none;
   margin: 0;
   direction:rtl;
   text-align:right;
   /*padding-left: .1em*/padding-right: .1em;
}

.presenceList li {
    /*padding: 0 0 0 .7em;*/padding: 0 .7em 0 0;
    margin-bottom: .2em;
}

Looks better now:

The results this far:

Next post – the tools in all their glory.

Back in Sakai 2.0 I went through an attempt to serve up a Right To Left language Sakai experience. At the time this was just an academic exercise, as there were no language resource bundles for Arabic, Hebrew, Farsi, etc. I just wanted to torture test the framework, frankly. It was amazingly simple to modify the portal framework via the skin to serve up an adequate portal. The tools were a different matter altogether, being so varied, and represented a number of challenges.

Now there is a Arabic translation (in trunk), so I thought I would go through the process again and hope it is useful. The framework has changed substantially also, so it was due. In this post I will outline the steps to turn a LTR portal (the Michigan CTools) into a RTL portal for some hypothetical university where Arabic is the main language. Disclaimer: I took Arabic in college, but it is long forgotten – so I am relying on random boilerplate and on iGoogle’s translator service for example strings. Don’t read too much into it!

In a future post I will go through one or two tools in a similar fashion.

1. Use trunk. Add ‘ar’ to the locales attribute in sakai.properties, start tomcat.
2. Login as admin. Create a user, give him a RTL name. In this case I used داود سيلڤَر (with a Latin id if you are not a RTL speaker, I used daud).
3. We will want داود to mess around with tools as ‘mantain’ to get the full experience so create a site and add him as mantain. I used boilerplate Arabic for site title and description.
4. Login as ‘daud’
5. Change your Preferences > Locales to ‘Arabic’

First thing – let’s add a direction attribute to first child of the portal body:

#portalOuterContainer{
	direction: rtl;
}

This gets us started. All HTML elements that inherit this attribute and use it will reverse direction. Now we need to address the elements that are not affected.

Some things will need to be addressed substantially: 1) the orientation of the mast head needs to be fixed so that from RTL: logo, banner, login; 2) site list orientation; 3) the portlet title (Announcements) also needs to be reconfigured as well; 4) finally – the portal content needs to be from RTL: tool links, content.

Reorienting the mast head

We have this mess to contend with:

I have outlined the three components in red. From LTR: #mastLogo, #mastBanner, #mastLogin. They are all floated. We need to reverse the order, so let’s reverse the float:

#mastLogin{
  /*float:right*/ float:left
}
#mastBanner{
  /*float:left*/float:right
}

That is it – really. Am omitting all of the other attributes. Which gives us:

The order of labels and inputs is following the direction attribute of the body. Everything else needs work. Am going to hide #mastLogo because we do not need it. Any graphic element can be poked in as a background of any of the (embarrassingly numerous) other canvases available. I will also add different logos and background colors.

So – new image for banner_inst.gif and reverse the padding orientation on #mastLogin:

#mastLogin{
	float: left;
	text-align: right;
	/*padding-right: 15px;*/padding-left: 15px;
	vertical-align: top;
}

Which leaves us with:

The language bundle seems to be missing the Arabic equivalents for the input labels, but the position basics are in place: logo to the right, login to the left.

Reorienting the site navigation

We are left with:

Swapping the floats (links and select) reflect the importance of the 2 in the RTL context:

#linkNav{
	/*float:right*/ float:left
}
#selectNav{
	/*float:left;*/ float:right
}

Although the the direction:rtl in the body gets us the RTL select, it does not flip the orientation of the inline list that the site links are, a list is a list and has an order. We will need to be more devious…

#siteLinkList li{
	display: inline;
	float:right;
}

Reorienting the content

#toolMenuWrap {
     border-right:2px solid #FFFFFF;
     color:#000000;
     /*float:left;*/ float:right
     padding:0 0.5em 0 0;
     text-align:right;
     width:9.6em;
}

and the margin of the other

#content{
	padding: 0;
	margin-top: .5em;
	/*margin-left: 11em;*/ margin-right: 11em;
}

and the text-align of the #toolMenu list items:

#toolMenu li{
	margin: 0;
	width: auto;
	padding: 0;
	border: 1px solid #fff;
	/*text-align: left;*/text-align: right;
}

Not bad, although quite a bit of clean up left to do (the presence block, the portlet titles (which are in the portal doc of all things) for example, the footers, etc.) And being ignorant of the actual use and needs, quite a few things I have overlooked as well – do leave comments setting me straight. I will upload the finished skin later. I will also address soon the skinning of the tools (gulp).

Suppose you want to relate several Sakai sites together. Some use cases:

1. a project site membership has a created a series of subsites to take care of committee work
2. you want to allow users of Fall 2008 course site access to all previous course sites for same course. You can take care of the access issues – but how to make it easier for them to find these other sites?
3. a department needs to provide a set of documents to all courses in it. The sites of these courses need to appear as “children” of the departmental site.
4. etc.

What to do? Pseudo-hierarchy might fit the bill. Run up at an airport by Chuck Severance it establishes a user-interface-only relationship between the sites. This takes place in a breadcrumb that displays below the site navigation paraphernalia.

The full details are here: sakai_pseudo_hierarchy.doc.

The rendering bits are in any version of Sakai after 2.4.x. – to customize for your institution – add the following lines (36-53 in Sakai 2.5.x) from the default.css and then change to suit.

/*site hierarchy breadcrumb*/
#siteHierarchy{
        clear:both;
        float:none;
        margin:0;
        list-style: none;
        padding:.5em 0;
}
/*style the standard breadcrumbseparator
   can set display:none if needed because the
   list-style is taking care of it*/
.breadSeparator{
}
#siteHierarchy li{
        display:inline;
}
#siteHierarchy li a, #siteHierarchy li a:visited{
        color:#09c;
}

You can also add your own separator via the language bundle.

1. Put this in the document (as well as a link to the jquery file).

<script type="text/javascript">
  $(document).ready(function(){
    setupLinks();
    setupPrintPreview();
  });
</script>

2. Put this in your external javascript:

function setupLinks(){
  $('a.print-window').click(function(){
     var w = window.open(this.href, 'printwindow', 'width=600,
          height=400,scrollbars=yes,resizable=yes');
     w.focus();
     return false;
  });
}

3. And this

function setupPrintPreview(){
  if (window.name == 'printwindow') {
   // all the settings below would need to be edited
    $('.portletBody *').css({
        color: '#000'
    });
    $('.bookList').show();
    $('.collapse').show();
    $('.expand').hide();
    $('.noPrint').hide();
    $('.portletBody').css({
        padding: '1em',
        fontSize: '.85em'
    });
    // provide a print link
    $("h3").append('a link with an
        'javascript:window.print()' href value);
  }
}

In (1) we are calling a function (2) that bind the onclick event to any link with a class of ‘print-window’ – opening the current document in a named window. In (3) – if a window matches the given name, then massage the elements for the print medium, hide elements that were classed as ‘noPrint’ (formish things, whatever), and add a link with an ‘javascript:window.print()’ href value to the DOM.

The end. Lots of room for improvement, of course – the massaging would be done best by swapping the stylesheets, for example.

The ability for an institution to configure their local Sakai instance with site types I think underexploited. Or maybe I do not know what people are doing with it. I show how to serve different look and feel for different site types using the same skin. But first – what is a site type?

Let’s say that your institution does not offer courses, but synergymnasiums, no seminars, but collaboratoriums, no discussion sections but hoedowns, etc. These choices can be presented to the user via configuration changes. But it goes beyond the name:  creation of different site types can be associated with different access level people. Maybe only administrators can create synergymnasiums, for example. Each site type also comes with a set of tools to choose from or forced to accept, and after 2.5.x, even with prebaked content into the bargain, etc. There is more to this that am aware of, but for our purposes here, the only thing that matters is that the site type is emitted as a class in the portal markup, allowing us to do different things to a portal depending on the site type. There are 3 spots where this happens:

In the portal masthead:

<div id="siteNavWrapper" class="workspace">
 <div id="mastHead">
  ....
 </div>
</div>

In the site navigation block:

<div class="siteNavWrap workspace">
 <div id="siteNav">
  ...
 </div>
</div>

and in the top most wrapping block of all site content:

<div id="container" class="workspace" >

This means that you can get at, via inheritance, to almost any element in the portal, and do different things to it based on the site type.

At the University of Michigan we have 5 significant site types: workspace, course, project, gradtools, and unspecified. Here is how the first three look like, using the same skin:

The user workspace:

The course site:

The project site:

Since a given user will go from workspace to project (at Michigan any user can create project sites) to course site it was important to make sure they were only subtly different – or different enough to help the user locate herself,  not different to force them to remap things between site types. This was done via color only – the color of the banner text (a background image of one of the children of the .mastHead block), the bottom border of the site navigation, the text of the site title, the text of the current tool, other things. The most radical difference was with the workspace banner text – we found our users needed that extra flag to discern between workspace and worksite.

You can take a look at the portal css of CTools if you would like. All of this is documented as well in the source documentation in the reference.

The remaining site type is the undeterminedSiteType – the default. That is literally the name of the class you need to address, or ignore but provide a css default for to take care of:

Since the default will be triggered when the site type is unspecified, and the only possible cases would be during errors (like Site Unavailable above) or admin type sites – where the stakes are high, the reddish color seemed warranted.

Anyways, this is all short on detail – but the documentation linked to above covers that pretty well.

Sakai has some functionality that may be of interest to solve particular problems but is not well known because:

• it has not been fully tested or
• was addressing very specific needs or
• is not well documented or
• has simply been forgotten

One of these is the Access Servlet. Have you wanted to point your group (define this as you will) to a specific slice of a Resource collection? Without all the Resource management paraphernalia of the Resource Tool? But will all the permissions in full operation? The Access Servlet is there to help.

1 – Choose “Edit Details” of the folder you want to share.

2 – Then click on the “Open” link

3 – The link will open a new window with the contents of the folder – but using the access servlet – looking like this:

All of the “file management” stuff is gone. Also the descriptions are available in the list itself (displayed by default – here toggled closed for the screen shot), which they are not in the OOTB Resources tool. The markup has been been pared down to the bone (an actual list with list items) and the scripting reduced to a nothing. More importantly – all of the access control settings for the whole selected hierarchy are intact – if Folder 2 contents is only available to members of a specific group only members of that specific group will see a link to it. Same obtains for all the other conditional disclosure settings of the folder.

Note and caveat: the functionality is available in Sakai 2.4 onwards, not sure who provided it – but the above screenshots are taken from a trunk build plus 2 patches  available at SAK-13694 and SAK-3804. Please read the comments to both for the caveats and gaps.

An enterprising developer could add an action to a Resource folder to automate this – perhaps adding a tool link targeting the slice to the tool navigation menu. Some institutions, like Oxford seem to be planning to use the access servlet as the main and only public face of the Resources tool it seems, not sure how they are going about that.

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.

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.

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.

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.

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