Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Getting "object" instance for calling methods

Reply
Thread Tools

Getting "object" instance for calling methods

 
 
My Pet Programmer
Guest
Posts: n/a
 
      12-24-2007
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!
 
Reply With Quote
 
 
 
 
Peter Michaux
Guest
Posts: n/a
 
      12-24-2007
On Dec 24, 6:14 am, My Pet Programmer <(E-Mail Removed)>
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, 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('myRollOver Element'));

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('myRo llOverElement'));

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
 
Reply With Quote
 
 
 
 
My Pet Programmer
Guest
Posts: n/a
 
      12-24-2007
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!
 
Reply With Quote
 
My Pet Programmer
Guest
Posts: n/a
 
      12-24-2007
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!
 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      12-24-2007
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.

 
Reply With Quote
 
My Pet Programmer
Guest
Posts: n/a
 
      12-24-2007
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!
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Static methods verus Instance methods lightning Java 4 10-30-2008 04:40 AM
Is there a way to find the class methods of a class, just like'methods' finds the instance methods? Kenneth McDonald Ruby 5 09-26-2008 03:09 PM
including instance methods and setting an instance variable Leon Bogaert Ruby 19 03-23-2008 09:29 PM
difference between class methods and instance methods John M. Gabriele Python 18 02-18-2005 05:17 PM
Why Petshop Changed all static methods to instance methods when upgrading from version 3.0 to version 3.1? Neo ASP .Net 1 01-07-2005 01:46 AM



Advertisments