Getting "object" instance for calling methods

M

My Pet Programmer

Ok guys, I'm really looking for someone to tell me how bad a hack this
is, and if I'm close to where I should be with it.

The basic situation is that I have a class which creates a basic
calendar control, the only difference is I stole the navigation scheme
from Vista (e.g., if you click on the year you zoom out to the months
list, then out to the decade, and back in when you click a year, then a
month).

I ran into some trouble setting the onclick events dynamically, then did
some reading on why I was getting a "too much recursion" error, which I
fixed. No problem. Now what I have is this:

function VistaCal() {
VistaCal.instance = this;
}

and then later on, when I am building the calendar controls:

mNameCell.onclick = function(){ updateCal("year", dateString);};

Where mNameCell is the year header, you click it, it zooms you out to
the list of months.

The updateCal function is outside the prototyping, and uses
VistaCal.instance to call the member function I need:

function updateCal(type, date) {
VistaCal.instance.displayChange(type, date);
}

I couldn't find any other way to get a reference to the current
VistaCal, and I looked. I fought with this thing for three hours last
night, and I got it working, but it feels like a hack.

Thoughts?

~A!
 
P

Peter Michaux

Ok guys, I'm really looking for someone to tell me how bad a hack this
is, and if I'm close to where I should be with it.

The basic situation is that I have a class which creates a basic
calendar control, the only difference is I stole the navigation scheme
from Vista (e.g., if you click on the year you zoom out to the months
list, then out to the decade, and back in when you click a year, then a
month).

I ran into some trouble setting the onclick events dynamically, then did
some reading on why I was getting a "too much recursion" error, which I
fixed. No problem. Now what I have is this:

function VistaCal() {
VistaCal.instance = this;

}

and then later on, when I am building the calendar controls:

mNameCell.onclick = function(){ updateCal("year", dateString);};

Where mNameCell is the year header, you click it, it zooms you out to
the list of months.

The updateCal function is outside the prototyping, and uses
VistaCal.instance to call the member function I need:

function updateCal(type, date) {
VistaCal.instance.displayChange(type, date);

}

I couldn't find any other way to get a reference to the current
VistaCal, and I looked. I fought with this thing for three hours last
night, and I got it working, but it feels like a hack.

I find it useful to think of a very simple widget that just does a
roll-over effect or a tabbed pane when thinking about widget
architecture. A calendar widget is too complex to program many
different ways in a half our each. I've programmed a tabbed pane about
20 times to try different code designs.

Here is a sketch of a roll over widget (short enough to type here
quickly) (not tested) the way I've been currently programming widgets.

function RollOverWidget(el) {
this.build(el);
}

RollOverWidget.prototype.build = function(el) {
this.el = el;
FORK.Event.addListener(el, 'mouseover',
this.handleMouseover, {scope: this});
FORK.Event.addListener(el, 'mouseout',
this.handleMouseout, {scope: this});
};

RollOverWidget.prototype.hoverClass = 'hovered';

RollOverWidget.prototype.handleMouseover = function() {
FORK.Dom.addClass(this.el, this.hoverClass);
};

RollOverWidget.prototype.handleMouseout = function() {
FORK.Dom.removeClass(this.el, this.hoverClass);
};

// use it. perhaps no need to keep a reference to the returned
object.
new RollOverWidget(document.getElementById('myRollOverElement'));

The Fork library is something I wrote and has served me well in my
work. The depth of namespacing could be reduced, the appropriateness
of the word "scope" has been contested here, the feature testing could
be improved, and the granularity of the files is too large. I think
you could just change the string "FORK" above to "YAHOO.util" and it
would work with the YUI library.

The code in the build function could be directly in the RollOverWidget
function but I extract it to the build function to make the prototype
a complete working prototype. This is not necessary but is to try to
embrace the prototype philosophy as much as possible.

The important part of the example is that after the RollOverWidget has
been "built" the handlers have reference to everything they need.
There is no searching through the DOM when the event handler runs.

Another way to program the roll over widget would be with a more
functional style

var hoverClass = 'hovered';

function handleMouseover(el) {
FORK.Dom.addClass(el, hoverClass);
}

function handleMouseout(el) {
FORK.Dom.removeClass(el, hoverClass);
}

function createRollOverWidget(el) {
FORK.Event.addListener(el, 'mouseover',
function() {handleMouseover(el);});
FORK.Event.addListener(el, 'mouseout',
function() {handleMouseout(el);});
};

// use it
createRollOverWidget(document.getElementById('myRollOverElement'));

In this example, the "el" is in the closure of the anonymous functions
sent to addListener. When the anonymous functions are run when the
user interacts with the page then they already have what they need. No
searching through the DOM.

I think it is worth programming these silly rollover widgets and then
a tabbed pane (less than 50 lines of code) every time I play with a
new architecture. The investment is small and the insight is worth it.

The second example (functional style) always seems to be shorter and
have more appeal to me but I've only programmed large widgets like the
first example (prototype OOP) as it has seemed easier to reuse code
and to extend the widget to make something like MyFancyRollOverWidget.

Peter
 
M

My Pet Programmer

Peter Michaux said:
I think it is worth programming these silly rollover widgets and then
a tabbed pane (less than 50 lines of code) every time I play with a
new architecture. The investment is small and the insight is worth it.

The second example (functional style) always seems to be shorter and
have more appeal to me but I've only programmed large widgets like the
first example (prototype OOP) as it has seemed easier to reuse code
and to extend the widget to make something like MyFancyRollOverWidget.

Peter

I think that was EXACTLY what I needed, the example of the event handler
in the class. I write big stuff, but I always brute-force my way through
it, trying to pick up from you guys a better way of doing things.

Seems to be working. Thanks, I really appreciate that.

~A!
 
M

My Pet Programmer

My Pet Programmer said:
Peter Michaux said:


I think that was EXACTLY what I needed, the example of the event handler
in the class. I write big stuff, but I always brute-force my way through
it, trying to pick up from you guys a better way of doing things.

Seems to be working. Thanks, I really appreciate that.

~A!
Oh, if you want to take a look:

http://mypetprogrammer.com/vistacal.html

It's just a little prototype at the moment, I'm working on the
architecture as of the moment I read your post.

~A!
 
R

Richard Cornford

My said:
Ok guys, I'm really looking for someone to tell me how bad
a hack this is, and if I'm close to where I should be with it.

The basic situation is that I have a class which creates a
basic calendar control,

By which the nearest you can mean is that you have an aggregation of
code that attempts to implement the concept of a 'class' in javascript,
as javascript has no 'classes' (or it has only one class; the native
ECMAScript object).
the only difference is I stole the navigation scheme from Vista (e.g.,
if you click on the year you zoom out
to the months list, then out to the decade, and back in
when you click a year, then a month).

I ran into some trouble setting the onclick events
dynamically, then did some reading on why I was
getting a "too much recursion" error, which I fixed.
No problem. Now what I have is this:

function VistaCal() {
VistaCal.instance = this;
}

If you assign the - this - value to a property of the constructor inside
the constructor then that means that there can only ever be one instance
of - VistaCal -, and if there can only ever be one instance it is
difficult to see how this can be a implementation of the concept of a
'class' in javascript (as 'classes' are things that are expected to have
multiple instances).
and then later on, when I am building the calendar controls:

mNameCell.onclick = function(){ updateCal("year", dateString);};

Where mNameCell is the year header, you click it, it zooms you
out to the list of months.

The updateCal function is outside the prototyping, and uses
VistaCal.instance to call the member function I need:

function updateCal(type, date) {
VistaCal.instance.displayChange(type, date); }

I couldn't find any other way to get a reference to the current
VistaCal, and I looked.

Closures are frequently employed in this context. See:-

I fought with this thing for three hours last night, and I got it
working, but it feels like a hack.

It would not be anybody's first choice to use a single global reference
to refer back to the object instance. But if there can only be one such
object and it is properly named (Your chosen name is obscure) then that
is not too big a deal. However, from the little code you posted it looks
like the creation of that single object could be much better handled,
and it would need much re-working if there were ever to be more than one
instance of that object.

Richard.
 
M

My Pet Programmer

Richard Cornford said:
It would not be anybody's first choice to use a single global reference
to refer back to the object instance. But if there can only be one such
object and it is properly named (Your chosen name is obscure) then that
is not too big a deal. However, from the little code you posted it looks
like the creation of that single object could be much better handled,
and it would need much re-working if there were ever to be more than one
instance of that object.

Richard.

Thanks for the extensive feedback, Richard, much obliged. The reason I
posted it here in the first place was because the way I did it there
could only be one, and I knew it was messed up. Luckily a couple of you
guys came along this morning and helped me out, and I'll rework it.

It's actually not a lot of rework that it needs, all the events are
handled from the same spot, so however I fix them there will propagate,
and heck, if it doesn't, I get to learn a bunch more about the technology.

And you'll have to forgive me thinking about things as objects for a
bit, I'm coming from an oo background, and Javascript's more advanced
features are a very different concept.

I really appreciate the response, thank you.

~A!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top