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

Re: [ydn-javascript] Browser History Manager: Bookmarked state vs. current state after initialization

Expand Messages
  • 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 1 of 2 , Jun 1, 2007
    • 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.