Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Tree2
    • Labels:
      None

      Description

      Cookies for tree2 are generated by JavaScript, with as name the (simple) JSF id of the tree2 component, and as path the "current URL directory". However, in a normal JSF-to-JSF navigation, the first time the tree is rendered, we came from another page, and the URL is the URL of that previous page (in JSF, the URL is always 1 step behind). When we have server interaction within the page the tree is on, after the first interaction, the URL is changed to the URL of the second page, and a second cookie is created for that "URL directory". This is not an issue in itself if both pages are in the same directory, but becomes apparent if they are not.

      This is probably hard to fix when looked at narrowly, because of the "URL is always 1 step behind" JSF issue. The real issue is, however, that the path of the cookie should be the webapp context, like JSESSIONID has, and not the "current URL directory". The viewId could then be made part of the cookie name, to make it unique.

      (Or, for an even more bold suggestion: we should get writ of the cookies, and store the state in a hidden field. Cookies can be used for storing state across requests, but for tree2 that is exactly what we don't want: we want to get the info to the server, let the server define a new state, and then get that back.)

        Activity

        Hide
        Mathias Werlitz added a comment -

        ...its been a long time...

        Well as I remember the preserve Toggle would work like this:

        • Tree2 on page A is toggled some way
        • User navigates to page B (normal jsf request OR direcly with a plain link)
        • User comes back somehow to page A

        The tree now looks the same as the user left page A, even if he did not submit the page. The browser supplies the most recent toggle data automatically with the second request for page A. With a hidden field this info would be lost.

        Show
        Mathias Werlitz added a comment - ...its been a long time... Well as I remember the preserve Toggle would work like this: Tree2 on page A is toggled some way User navigates to page B (normal jsf request OR direcly with a plain link) User comes back somehow to page A The tree now looks the same as the user left page A, even if he did not submit the page. The browser supplies the most recent toggle data automatically with the second request for page A. With a hidden field this info would be lost.
        Hide
        sean schofield added a comment -

        Would this really break preserve toggle? Couldn't we just add the toggled nodes to the hidden field via javascript instead of adding them to cookies?

        Show
        sean schofield added a comment - Would this really break preserve toggle? Couldn't we just add the toggled nodes to the hidden field via javascript instead of adding them to cookies?
        Hide
        Mathias Werlitz added a comment -

        getting rid of cookies would breake the preserveToggle feature in client side toggle mode

        Show
        Mathias Werlitz added a comment - getting rid of cookies would breake the preserveToggle feature in client side toggle mode

          People

          • Assignee:
            sean schofield
            Reporter:
            Jan Dockx
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development