> One thing though: it's not always enough to store > only the object's id: > > imagine the case of the collapsible panel, or a > server side switched > tabbed panel, where the full information is not > always wrapped in the > http-request. For these cases, you'll need to > provide a possibility to > save data in between requests without using the > database directly or > the HTTP parameters. What is your position on this? >
Do you mean that the object cannot be stored in the database for several consequent HTTP requests? Is it similar to "wizard-problem" where I have to develop several steps that modify an object and store it only after the last step has succeded? If so then it indeed cannot be solved in a way I described. We have developed an approach to handle such situations but it currently suffers from thread safety problems. We have a notion of "copy" - instance of a persistent object that is detached from a database. It is modified but not synchronized with db until explicitely persisted. We have to store it inside HTTP session of course. We are planning to return to this feature right after Rumba release. Regards, Alexey __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
