Here is my thought because I think there are other places in core that use persist.
I think the idea behind persist is you leave the argument blank which allows you to override the type via the metadata. If no overrides are found it falls back to the default which is session. It appears you could override the default with client but that seems like a bad idea. I'm sure there are many people (me included) that persist db result sets in the session. So here is my suggestion: Create a persist-override module that does the following 1. Create a "PersistChain" type that implements chain of command 2. Create a ValueEncoder for DefaultTreeExpansionModel 3. Create a PersistByType provider that uses value encoders to persist in the client and put it in the chain. 4. Replace the default persist type with PersistChain Now you can control by datatype the default persist method. You can also override this by placing other providers in the chain and you can still override things with Meta. Lastly the default type is still Session. Issues: 1. It might be better to have a PersistByType mapped configuration instead of using ValueEncoder directly. There might be times when you have a ValueEncoder but don't want the change the persist type. So if you want PersistClient for components in core you just add this module to your pom file and it magically works. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Does-the-Tree-component-need-to-use-the-session-tp5667428p5670216.html Sent from the Tapestry - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
