Renderer decorators, component listeners

Antranig Basman Antranig.Basman at
Sat Nov 28 04:13:08 UTC 2009

Hi there Boyan... I had a look over the code in SVN but the workflow 
seems a bit confused... firstly there seem to be attempts to instantiate 
a reorderer both from outside the rendering loop and then as a decorator 
from inside the tree. The reorderer written at top level binds to the 
markup before it is rendered... and so instantiates a reorderer which 
only binds to one element. I tried exchanging the order of rendering and 
the reorderer decorator, and this produced an example which seemed to 
work. However, you seem to have written a decorator *INSIDE* the 
fluid.transform call - which actually instantiates four separate 
reorderers where I assume only one is required. Perhaps there is an 
indentation problem in the file? I notice that the file Capture.js 
contains a mixture of tab and space characters which generally makes for 
problems when interpreting, at least to humans - unfortunately this is 
notoriously difficult to fix within Eclipse since the various Javascript 
editors have various conventions for how to control whitespace - but see 
if you can somehow manage to find the correct options to select spaces 
only for you.

Really only ONE fluid.reorderImages decorator should be supplied, so it 
should be written outside the transform loop - but since it is happy to 
bind at a higher level than any node which is actually rendered, there 
is really not an architectural problem simply instantiating the 
reorderer as a separate activity to rendering - the best version I 
produced from your code commented out the decorator entirely, and 
exchanged the order of the calls to "render" and the initSubcomponents 
call. This instantiates a single reorderer which seems to work correctly.

In terms of your "returnedOptions" question, this is a method of making 
configuration more declarative by returning options from a subcomponent 
to a top-level component - the alternative to this is to issue standard 
function calls, say, to register listeners in code rather than in 
configuration. In Fluid we are generally attempting to move as much 
infrastructure into configuration as possible as opposed to writing code 
- but we generally admit that the "returnedOptions" scheme is not an 
ideal design and will be amongst the several things which will be 
superseded by the new IoC system in the new release - so I would not 
invest too much effort in trying to understand it :)

"bindHandlers" is a not terribly official convention for part of a 
component's workflow that involves attaching listeners to DOM elements. 
I think part of your confusion between "returnedOptions" and 
"bindHandlers" comes from not distinguishing between "Fluid events" and 
"DOM events". "returnedOptions" is a scheme which is primarily useful 
for getting handlers registered to Fluid events - Fluid events exist 
primarily at the model level (M of MVC) and are do not in general 
interact with the DOM. Whereas "bindHandlers" is typically used for 
registering listeners to the DOM (V of MVC).

There is a good guide to "Events" (Fluid Events) on the "Framework 
Concepts" page on the wiki:

Let me know if this resolved the issues you are having and answered your 

Boyan Sheytanov wrote:
> Hi Michelle!
> I've moved the code from thumbBrowser to Capture and all of a sudden
> it stopped working! The markup is rendered correctly but the image
> reorderer does not work. I've added a fluid decorator to the component
> tree just as I did in thumbBrowser. Still, it doesn't seem to work,
> while the same code in the thumbBrowser works. I think I'm hitting an
> obvious blocker that I cannot see because of looking at the same code
> over and over again. Will you please have a look? I've commited the
> code in the repository:
> Another topic I'm uncertain about is the bindHandlers method (in the
> same Capture.js file). I saw something similar in another component
> and tried to reuse it, but am not sure what exactly the
> that.returnedOptions statement is about and why it does the job. An
> explanation on this would be quite helpful. Suggestion for a better
> way for implementing the same functionality is welcome (now there are
> no meaningful handlers bound, but if you write alert("it works"), it
> works :)).
> Any help will be appreciated.
> Greetings,
> Boyan
> _______________________________________________________
> fluid-work mailing list - fluid-work at
> To unsubscribe, change settings or access archives,
> see

More information about the fluid-work mailing list