Saving table sort preferences

With property IDs allowed to be any class, and table sorting done by column property ID, I can’t think of a way to store the current sort state of a column between user sessions, so I can sort a table the same way the next time the user logs in.

I know I could write something on a per-table basis to do it, but I want a general augmentation to Table, to specifically avoid that, as our application will have over 100 tables.

Anyone have any thoughts? I want the solution to be stable even if we add properties to a table’s container later (I’d handle removed properties by reverting to a default sort), and even if a container returns its properties in a Collection with arbitrary and unstable ordering, as that method is typed to Collection, not List.

Can’t assume Serializable, as some containers may just use Object static constants for property IDs, and Object isn’t Serializable, of course. And even if we could enforce all Property IDs implement Serializable, that still doesn’t guarantee the property instance in one session would be .equals() to the deserialized ID from another session, for instance if the objects used default Object.equals(), which is really ==.

Our old application version had generic sort preference persistence, so this is becoming a bit of a sticky issue, as we had not anticipated extensive development to customize each table individually for sort preference persistence.

What kind of a container are you using? For example, when using a BeanItemContainer, the property ids are always strings, and hence you could store a set of string representing the sort order. I think the same thing applies for other generic containers which are automatically populated based on some existing data, such as the JPAContainer. Even though the interface defines that property ids can be any object, I personally always use strings.

We don’t like String as a property/column ID because typos aren’t found until runtime. Similarly, bean properties can change with refactoring, and using String property values negates compile-time checking. Constants are better, but we often like to encapsulate more behavior in the ID, and still have the refactoring problem.

We are using quite a few Enum classes as IDs instead, where each instance implements value getter/setter methods to access specific data object properties.

I went with the least restrictive persistence I could think of, short of supporting Object itself - Serializable. As long as IDs and the beans that are used to retain/restore them include that marker interface, I can persist settings between sessions.

For our purposes that means zipping an Object Stream and storing it in a database field. That way the container and item implementations don’t matter, which we need, as we have custom ones for various specialized parts of our application, and we can keep UI settings separated from data implementations.

We still have refactoring/code history issues to watch out for, as changing the structure of the saved state object class will break deserialization of old user settings.