Tapestry
  1. Tapestry
  2. TAPESTRY-738

Create ability to use SqueezeAdaptors for @Persist("client:app")

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.0
    • Fix Version/s: 4.1.2
    • Component/s: Framework
    • Labels:
      None

      Description

      From the doc:
      "client
      Client properties are stored on the client, in the form of query parameters. All persistent properties for each page are encoded into a single query parameter, named state:PageName. The query parameter value is a MIME encoded byte stream. This can get quite long if there are many client persistent properties on the page ... which may quickly run into limitations on the maximum size of a URL (approximately 4000 characters is a good guideline). This is less a problem for forms."

      Could it be made possible to use DataSqueezers for this?
      Or can you perhaps give me pointers what to change to create my own persistence scheme so I could client persist simple strings and ints as what the are so the urls will be much more nice. This would be really cool so to keep everything httpsession-less

        Activity

        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        568d 19h 18m 1 Jesse Kuhnert 28/May/07 19:22
        Mark Thomas made changes -
        Workflow Default workflow, editable Closed status [ 12567933 ] jira [ 12591056 ]
        Mark Thomas made changes -
        Workflow jira [ 12343457 ] Default workflow, editable Closed status [ 12567933 ]
        Jesse Kuhnert made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Assignee Jesse Kuhnert [ jkuhnert ]
        Hide
        Jesse Kuhnert added a comment -

        I've made most of the important methods / fields protected in a few choice places to make it easier for people to plug in their own persistence strategies without having to re-create everything from scratch.

        Of course- if people do have some fancy new strategies for doing this we would love to see some patches / code contributed back.

        Show
        Jesse Kuhnert added a comment - I've made most of the important methods / fields protected in a few choice places to make it easier for people to plug in their own persistence strategies without having to re-create everything from scratch. Of course- if people do have some fancy new strategies for doing this we would love to see some patches / code contributed back.
        Jesse Kuhnert made changes -
        Fix Version/s 4.1.1 [ 12312021 ]
        Fix Version/s 4.1.2 [ 12312202 ]
        Jesse Kuhnert made changes -
        Fix Version/s 4.1 [ 12310632 ]
        Fix Version/s 4.1.1 [ 12312021 ]
        Jesse Kuhnert made changes -
        Fix Version/s 4.1 [ 12310632 ]
        Fix Version/s 4.0.3 [ 12310994 ]
        Andreas Andreou made changes -
        Field Original Value New Value
        Fix Version/s 4.0.3 [ 12310994 ]
        Hide
        Mark Lehmacher added a comment -

        Regarding this issue it would be useful to change "private" visibility of the two methods "writeChangesToStream" and "readChangesFromStream" in org.apache.tapestry.record.PersistentPropertyDataEncoderImpl to "protected". That way one could hook in the DataSqueezer into saving/restoring the property change values by extending aformentioned class.

        For that matter it might make even more sense to introduce more fine-grained methods which deal with converting to and from PropertyChange objects and which are called from the respective read and write changesToStream methods.

        Show
        Mark Lehmacher added a comment - Regarding this issue it would be useful to change "private" visibility of the two methods "writeChangesToStream" and "readChangesFromStream" in org.apache.tapestry.record.PersistentPropertyDataEncoderImpl to "protected". That way one could hook in the DataSqueezer into saving/restoring the property change values by extending aformentioned class. For that matter it might make even more sense to introduce more fine-grained methods which deal with converting to and from PropertyChange objects and which are called from the respective read and write changesToStream methods.
        Wouter de Vaal created issue -

          People

          • Assignee:
            Jesse Kuhnert
            Reporter:
            Wouter de Vaal
          • Votes:
            5 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development