Antranig Basman antranig at
Fri May 25 21:32:41 UTC 2007

Thinking a bit further after our meeting, I realise there will 
actually never be any need for client-side DOM duplication
assuming it receives a proper initial kit from the server - 
all that's needed would be keeping the hidden (or otherwise)
numeric submission controls in step with the manipulated order.

You can see our version of this control in the Evaluation tool
(it uses JQuery for DnD and visible HTML <select> controls for
the numeric submission) in the "Modify Template Items" view.

Here is the view URL

Javascript is here:

(the draggable items are the ones with rsf:id="item-row:", the
template's namebase prefix is simply "" - unclear whether this
control will actually *work* when unhoused from this view/namebase
since that hasn't been part of the spec or tested - but the
basic logic outline is there)

In particular lines like this 
            var itemSelect = document.getElementById(itemId + "item-select-selection");

are very typical computations of the sort you tend to see on
RSF-rendered IDs.

Here is another very idiomatic block from "evalUtils.js" - this is the
function called by the traditional one-line-init call that follows
RSF component instances:

  decorateReorderSelects: function(namebase, count) {
      var buttonid = namebase + "hiddenBtn";
      var button = $it(buttonid);
      for (var i = 0; i < count; ++ i) {
        var selectid = namebase + "item-row::"+i+":item-select-selection";
        var selection = $it(selectid);
        selection.onchange = function() {;


  function $it(elementID) {
    return document.getElementById(elementID);

Hope this makes some sense in terms of our discussion before - 
the point is that on the clientside this can be really simple :P

And on the server-side also...


More information about the fluid-work mailing list