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

Browser History Manager: Bookmarked state vs. current state after initialization

Expand Messages
  • lenzbd
    I have a question about possible differences (on load) between the bookmarked state of a module on load and the current state of a module after BHM
    Message 1 of 2 , Jun 1 12:48 PM
    • 0 Attachment
      I have a question about possible differences (on load) between the
      bookmarked state of a module on load and the "current state" of a
      module after BHM initialization.

      From the docs re: the BHM's "onLoad" event:

      "One common task you'll find yourself executing in your Browser
      History Manager onLoad event handler is retrieving the current state
      of your module and updating its UI accordingly."

      I'm curious why you need to wait until after the BHM has initialized
      to determine this as opposed to just using getBookmarkedState to
      determine if the UI needs to be updated. I don't see any scenarios
      (in FF, IE, Safari) where this is necessary. The benefit of just
      using the bookmarked state and comparing it to the initial state of
      your page is that you can make immediate UI changes to the page
      without first waiting for the page to finish loading.

      For example, in my case, I'm using AJAX to update one section of the
      page. Upon browsing to another page and then using the back button to
      return to it, if I wait until after load to update the UI, then the
      initial state of the page will appear until the page has completed
      loading after which point I can update the page. This leads to a
      fairly jarring effect of causing the page contents to be displayed
      briefly, then disappear, and then the correct UI appears.

      Instead, if I use inline javascript, I can hide the initial div
      immediately rather than wait for the onload event to be triggered.

      Am I missing something? Is there any reason (cross-browser
      compatibility issues, etc.) not to take this approach?

      Brian
    • Julien Lecomte
      Hello Brian, It is absolutely essential to wait until after the BHM has been initialized to determine in which state a module is (using the getCurrentState()
      Message 2 of 2 , Jun 1 1:33 PM
      • 0 Attachment
        Hello Brian,

        It is absolutely essential to wait until after the BHM has been
        initialized to determine in which state a module is (using the
        getCurrentState() method). This is because of the way the BHM works on
        IE and because we thrived to offer a consistent interface to the
        programmer on all browsers. The details are a bit complicated to explain
        so I'll let you poke around in the code. Let me know if you have any
        further questions.

        Regards,
        Julien Lecomte


        On Fri, 2007-06-01 at 19:48 +0000, lenzbd wrote:
        > I have a question about possible differences (on load) between the
        > bookmarked state of a module on load and the "current state" of a
        > module after BHM initialization.
        >
        > From the docs re: the BHM's "onLoad" event:
        >
        > "One common task you'll find yourself executing in your Browser
        > History Manager onLoad event handler is retrieving the current state
        > of your module and updating its UI accordingly."
        >
        > I'm curious why you need to wait until after the BHM has initialized
        > to determine this as opposed to just using getBookmarkedState to
        > determine if the UI needs to be updated. I don't see any scenarios
        > (in FF, IE, Safari) where this is necessary. The benefit of just
        > using the bookmarked state and comparing it to the initial state of
        > your page is that you can make immediate UI changes to the page
        > without first waiting for the page to finish loading.
        >
        > For example, in my case, I'm using AJAX to update one section of the
        > page. Upon browsing to another page and then using the back button to
        > return to it, if I wait until after load to update the UI, then the
        > initial state of the page will appear until the page has completed
        > loading after which point I can update the page. This leads to a
        > fairly jarring effect of causing the page contents to be displayed
        > briefly, then disappear, and then the correct UI appears.
        >
        > Instead, if I use inline javascript, I can hide the initial div
        > immediately rather than wait for the onload event to be triggered.
        >
        > Am I missing something? Is there any reason (cross-browser
        > compatibility issues, etc.) not to take this approach?
        >
        > Brian
        >
        >
        >
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.