Miserable Mono and the Paged Bonobo

Steven Githens swgithen at mtu.edu
Thu May 21 16:01:59 UTC 2009


Hi Fluid,

I've ran into this particular issue I'm about to describe a few times 
now, and not being a real javascript programmer yet, I'm wondering if 
someone can fill me in on a way to do this.

The most recent time this has occurred has been just now while I was 
working on the Pager.

So, take for example the Pager, defined in Pager.js and using what seems 
to be the standard fluid-crockfordlike way of defining things.

(fluid ($, fluid) {

function expandColumnDefs(filteredRow, opts) { ... };

// other privately closured things

fluid.pager.selfRender = function (overallThat, inOptions) {
    // code
    expandColumnDefs(row, opts);
    // code
};

// other public fluid attached things

})(jQuery, fluid_1_1);

At this point I'm filling the persona of the application programmer, 
(which is really what I am at this point),  consuming fluid widgets and 
regurgitating them into my application for our hungry users.

Now, I've ran into a situation where I want to fiddle around with a 
different selfRender function for my pager.  Sure I can write a render 
function no problem, but I want to write a first class selfRender 
function that actually takes advantage of the pager, model, and all it's 
functionality.

So... how do I resuse all those private closured functions which are 
necessary to really extend the pager?  Information hiding is cool and 
trendy, but as the programmer I'm used to being able to get access to it 
if I really want to and need to.  If you really need something in Java 
that is private you can just use reflection[1] or a real programming 
language like JRuby or Jython.  If you *really* need something that is 
meant to be hidden in Python you can always get it, even though you'll 
have to go through the objects internal dictionary and look for the 
underscore(s)+unique integer that obfuscates the entry.  But in reality, 
if you're actually extending these things you can get to them no sweat.

I haven't figured out how to do that yet with this object pattern.  I 
was thinking that maybe there would be part of the javascript language, 
like a special builtin variable that would allow me to get access to the 
closure so I could reuse those methods and data.

It's problematic because if you are an end user using InfusionAll.js you 
have to reconfigure you're whole tool chain to now include individual 
files, or maybe you can just include Pager.js on top of InfusionAll.js 
and it nicely just redefine the pager functions ( I haven't tried that 
yet ).   But either way, it seems the only way to extend the 
functionality of the Pager ( or any component ), is to actually put your 
extensions in the same source file from the framework.  My knees are 
kind of trembling at this idea.

But hopefully I'm wrong and there is someway to access that stuff.  It's 
not just the pager, I've had this issue when I was using some of the 
other components and framework parts.  I'm sure an immediate response 
from a lot of people to this is... "You shouldn't do it that way!!", but 
it's still scary that the only way to extend something, or prototype new 
functionality, or monkey patch anything is to replace and edit the 
actual entire source file from the framework.

           - - -

Other than that I'm having a lot of fun.  Adding a lot of Fluid stuff to 
Asnn2, putting in my second Fluid pager on it right now.   
Fluid.transform(obj,idx) is freaking awesome.

Megacheers,
Steve

[1] Unless you set that JVM property or whatever that disables private 
reflection






More information about the fluid-work mailing list