Getting "object" instance for calling methods

[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!

[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!

[My Pet Programmer]

My Pet Programmer said:

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!

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!

[Richard Cornford]

My Pet Programmer wrote:

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:-

<URL: http://jibbering.com/faq/faq_notes/closures.html >

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.

[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!