I was actually messing with this 2 days ago. I created a custom impementation of PersistentPropertyDataEncoder that instead of using ObjectOutputStream.writeObject (in writeChangesToStream ) checks the type of the object and outputs a prefix + accordingly uses ObjectOutputStream.writeFloat, ObjectOutputStream.writeUTF, ObjectOutputStream.writeLong e.t.c. It also handles nulls by using a special prefix. Anyway, by using this approach, i got the Base64 encoded string down to 1/3 of its size. I was also thinking of injecting the DataSqueezer in my custom PersistentPropertyDataEncoder but the squeezer turns object to strings and this cannot take advantage of the writeLong, writeFloat e.t.c. methods of the ObjectOutputString.
Perhaps these 2 modules need a bit of refactoring in order for one to make use of the other. >All, > >I have been going crazy trying to figure out why my client-persisted page >properties aren't being "unsqueezed" by my custom squeezer. Well, it's >because Tapestry doesn't use the "squeezer" to store client-persisted page >properties >(http://mail-archives.apache.org/mod_mbox/jakarta-tapestry-dev/200507.mbox/% >[EMAIL PROTECTED]). Has anyone ever >implemented a SqueezerPropertyPersistenceStrategy? What I'm trying to do is >merely write the id of an entity object out to the client and use that to >reconstruct the object when it comes back up (using Hibernate of course). > >James > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
