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

Re: Browser History Manager: allow multiple module state changes at once

Expand Messages
  • lenzbd
    Thanks, Julien! I ve been working on the problem a bit more, and figured out that what I actually want is the ability to have the state support complex JSON
    Message 1 of 4 , Jun 1, 2007
    • 0 Attachment
      Thanks, Julien!

      I've been working on the problem a bit more, and figured out that what
      I actually want is the ability to have the state support complex JSON
      objects as opposed to just strings. This way, I can have a single
      module that has a state represented by a complex object with multiple
      parameter values. The Browser History Manager would internally
      determine how to serialize the object into the hash values.

      This behavior is slightly different than what I initially requested in
      that I really don't want to have multiple modules in my use case. I
      just want a single module with multiple parameters. This way, when
      using the back button, BHM won't trigger a state change for each of my
      separate modules. I really just want a single state change for my
      multi-parameter module.

      For now, I'm just going to handle encoding multiple parameters into a
      single state string.

      Brian

      --- In ydn-javascript@yahoogroups.com, Julien Lecomte <jlecomte@...>
      wrote:
      >
      > Hello Brian,
      >
      > I have some good news for you! This feature was already requested
      > several weeks ago on this list, and will be implemented for the next
      > version of YUI. Stay tuned!
      >
      > Regards,
      > Julien Lecomte
      >
      >
      > On Fri, 2007-06-01 at 17:15 +0000, lenzbd wrote:
      > > I've just started integrating the Browser History Manager into our
      > > application and one piece of functionality that I would like to see
      > > added is the ability to change module state for multiple modules via a
      > > single navigate command.
      > >
      > > In my case, I have 4 separate modules (essentially just parameters)
      > > that correspond to the same section of the page. I sometimes need to
      > > change more than one of the parameters at a time, but do not want a
      > > separate history entry created for each. It would be great if I could
      > > update the 4 separate modules in a single update, which will result in
      > > the AJAX request only happening once for the entire operation as
      > > opposed to once for each module change.
      > >
      > > Without this functionality, I'm forced to come up with my own
      > > parameterization technique for encoding all 4 of my parameters into a
      > > single module state representation.
      > >
      > > Am I just trying to misuse the intended usage of a module? Is there
      > > some better alternative that I'm missing?
      > >
      > > Thanks in advance for any recommendations you can provide :)
      > >
      > > Brian
      > >
      > >
      > >
      > >
      > >
      >
    • Julien Lecomte
      It is an interesting feature request. Right now, the state parameter you pass to navigate() must be a string. In the future, it could be any object, and the
      Message 2 of 4 , Jun 1, 2007
      • 0 Attachment
        It is an interesting feature request. Right now, the state parameter you
        pass to navigate() must be a string. In the future, it could be any
        object, and the BHM would serialize/deserialize it automatically.
        Interesting! Let me think about it...

        --
        Julien


        On Fri, 2007-06-01 at 17:41 +0000, lenzbd wrote:
        > Thanks, Julien!
        >
        > I've been working on the problem a bit more, and figured out that what
        > I actually want is the ability to have the state support complex JSON
        > objects as opposed to just strings. This way, I can have a single
        > module that has a state represented by a complex object with multiple
        > parameter values. The Browser History Manager would internally
        > determine how to serialize the object into the hash values.
        >
        > This behavior is slightly different than what I initially requested in
        > that I really don't want to have multiple modules in my use case. I
        > just want a single module with multiple parameters. This way, when
        > using the back button, BHM won't trigger a state change for each of my
        > separate modules. I really just want a single state change for my
        > multi-parameter module.
        >
        > For now, I'm just going to handle encoding multiple parameters into a
        > single state string.
        >
        > Brian
        >
        > --- In ydn-javascript@yahoogroups.com, Julien Lecomte <jlecomte@...>
        > wrote:
        > >
        > > Hello Brian,
        > >
        > > I have some good news for you! This feature was already requested
        > > several weeks ago on this list, and will be implemented for the next
        > > version of YUI. Stay tuned!
        > >
        > > Regards,
        > > Julien Lecomte
        > >
        > >
        > > On Fri, 2007-06-01 at 17:15 +0000, lenzbd wrote:
        > > > I've just started integrating the Browser History Manager into our
        > > > application and one piece of functionality that I would like to
        > see
        > > > added is the ability to change module state for multiple modules
        > via a
        > > > single navigate command.
        > > >
        > > > In my case, I have 4 separate modules (essentially just
        > parameters)
        > > > that correspond to the same section of the page. I sometimes need
        > to
        > > > change more than one of the parameters at a time, but do not want
        > a
        > > > separate history entry created for each. It would be great if I
        > could
        > > > update the 4 separate modules in a single update, which will
        > result in
        > > > the AJAX request only happening once for the entire operation as
        > > > opposed to once for each module change.
        > > >
        > > > Without this functionality, I'm forced to come up with my own
        > > > parameterization technique for encoding all 4 of my parameters
        > into a
        > > > single module state representation.
        > > >
        > > > Am I just trying to misuse the intended usage of a module? Is
        > there
        > > > some better alternative that I'm missing?
        > > >
        > > > Thanks in advance for any recommendations you can provide :)
        > > >
        > > > Brian
        > > >
        > > >
        > > >
        > > >
        > > >
        > >
        >
        >
        >
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.