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