Loading ...
Sorry, an error occurred while loading the content.

Connection Mngr: How many callback objects should be used in an app?

Expand Messages
  • than505
    I am trying to create a simple app to read contact information from a database using an ajax call with the connection manager. The server sends back an XML
    Message 1 of 3 , Jun 28, 2006
    • 0 Attachment
      I am trying to create a simple app to read contact information from a
      database using an ajax call with the connection manager. The server
      sends back an XML file which the javascript then turns into HTML for
      the browser.

      Each line might list a contacts name, another line the various
      locations of a given contact. Each of these has 2 buttons, an "edit"
      button (calls a function which replaces the contact's name on the
      screen with 2 text
      boxes for the first/last names) and an "update" button to send to the
      server.

      The problem I am finding is that because I have various buttons for
      editing/updating info, each of these calls a different function which
      then needs another callback object to deal with the server reponse.

      I am starting to get over a dozen callback objects. Am I using this
      Y!CM in the wrong way?

      How many callback objects should one be using in a smallish
      application? And is it recommended to use what I have read are
      "namespaces" to avoid placing so many functions/callback objects in
      the global scope?

      Any direction in this matter is greatly appreciated.
    • than505
      No one want to throw down a few words of direction?
      Message 2 of 3 , Jun 28, 2006
      • 0 Attachment
        No one want to throw down a few words of direction?
      • Thomas S. Sha
        ... If you have n number of buttons, but there are only two types -- edit and update -- it seems to me you could normalise the edit and update functions. Can
        Message 3 of 3 , Jun 29, 2006
        • 0 Attachment
          --- In ydn-javascript@yahoogroups.com, "than505" <than505@...> wrote:
          > Each line might list a contacts name, another line the various
          > locations of a given contact. Each of these has 2 buttons, an "edit"
          > button (calls a function which replaces the contact's name on the
          > screen with 2 text
          > boxes for the first/last names) and an "update" button to send to the
          > server.
          >
          > The problem I am finding is that because I have various buttons for
          > editing/updating info, each of these calls a different function which
          > then needs another callback object to deal with the server reponse.

          If you have n number of buttons, but there are only two types -- edit
          and update -- it seems to me you could normalise the edit and update
          functions. Can you provide an example code for a function called on
          button click?

          > I am starting to get over a dozen callback objects. Am I using this
          > Y!CM in the wrong way?

          If you have a dozen disparate tasks within a persistent UI, this
          doesn't seem to be out of bounds, but the task you've described
          suggests perhaps a callback(or a few) can be shared to accomodate
          common tasks?

          > How many callback objects should one be using in a smallish
          > application? And is it recommended to use what I have read are
          > "namespaces" to avoid placing so many functions/callback objects in
          > the global scope?

          If the application is entirely within your purview, then probably not.
          If there is any possibility of the application scaling up, reuse, or
          other developers contributing to the project, then you might consider
          aggregating the callbacks into some sort of "map"; or, namespace your
          application with your callbacks under its scope.

          Regards,
          Thomas
        Your message has been successfully submitted and would be delivered to recipients shortly.