Miserable Mono and the Paged Bonobo

Colin Clark colin.clark at utoronto.ca
Thu May 21 17:35:30 UTC 2009


Steve,

Wow, good questions. My thoughts:

1. Having to modify someone else's code directly is A Bad Thing.
2. Information hiding is only cool if hiding something makes life  
easier for application developers.

So, I totally agree that your knees should tremble at the thought of  
having to stick your own code inside of files we ship with Infusion.  
That's just terrible. Similarly, one of our primary goals with  
Infusion has been to try to make the framework and components as  
permeable as possible, without risking naming conflicts. In other  
words, we really try to not hide useful stuff away.

Unfortunately, there's nothing in JavaScript that will allow you to  
crack open a closure's scope and access private variables. That's  
probably a good thing. If it hasn't been exposed publicly, it's just  
not there for you. So, I think you've found a bug. expandColumnDefs  
contains code you find useful and want to reuse: it should be publicly  
available.

I can certainly file a bug about this specific issue for you. The  
larger point is one for us all to remember as we're developing  
components. If your code is even vaguely useful, share it with your  
users by making it publicly available!

Colin

On 21-May-09, at 12:01 PM, Steven Githens wrote:

> 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
>
>
>
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work

---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org




More information about the fluid-work mailing list