Getting "object" instance for calling methods

Discussion in 'Javascript' started by My Pet Programmer, Dec 24, 2007.

  1. 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, Dec 24, 2007
    #1
    1. Advertising

  2. On Dec 24, 6:14 am, 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, 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
     
    Peter Michaux, Dec 24, 2007
    #2
    1. Advertising

  3. 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, Dec 24, 2007
    #3
  4. 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!
     
    My Pet Programmer, Dec 24, 2007
    #4
  5. 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.
     
    Richard Cornford, Dec 24, 2007
    #5
  6. 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!
     
    My Pet Programmer, Dec 24, 2007
    #6
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Neo
    Replies:
    1
    Views:
    549
    Scott Allen
    Jan 7, 2005
  2. John M. Gabriele
    Replies:
    18
    Views:
    1,224
    Steven Bethard
    Feb 18, 2005
  3. lightning
    Replies:
    4
    Views:
    942
    Daniel Pitts
    Oct 30, 2008
  4. Leon Bogaert
    Replies:
    19
    Views:
    356
    Robert Klemme
    Mar 23, 2008
  5. Kenneth McDonald
    Replies:
    5
    Views:
    386
    Kenneth McDonald
    Sep 26, 2008
Loading...

Share This Page