Exactly, use the preserveDataModel attribute and you are all set! Manfred had a very hard time implementing that one, as far as I remember ;)
regards, Martin On Mon, 31 Jan 2005 23:56:00 -0500, Sean Schofield <[EMAIL PROTECTED]> wrote: > There are definitely a lot of situations where you would expect the > data to change like this. The program I am working on right now is > an application that users use during the course of the day to update > their progress on various documents. Often times you will have > multiple people making changes to those documents at similar times. > Of course the default should be to skip storage of the data model so > that in your case where you don't worry about that sort of thing, you > don't have the overhead of storing the model. > > Also, there are plenty of times where the changes in the data model > won't cause a problem. A table that displays a report that is read > only will not be an issue. Its only when you have a hyperlink or > editable value in the table where you could potentially run into > problems. > > Anyways it sounds like this feature is already available in > x:dataTable. Nice :-) > > sean > > On Mon, 31 Jan 2005 22:25:05 -0600, Heath Borders > <[EMAIL PROTECTED]> wrote: > > Well, I guess I'm thinking that you're in a somewhat specialized case > > where you cannot guarantee synchronized access to data throughout a > > session. > > > > For me, I'm generally able to do simple CRUD operations without the > > data changing behind me. I could see that being a problem though if > > multiple users are allowed access to the same data. > > > > > > On Mon, 31 Jan 2005 18:11:10 -0500, Sean Schofield > > <[EMAIL PROTECTED]> wrote: > > > > Your explanation of the problem here makes a little more sense to me > > > > now. I support this change. Hopefully, most people wouldn't have to > > > > use it, but if you're operating with really volatile data, I could see > > > > how it could solve a lot of problems. > > > > > > What do you mean by "really volatile data"? It would seem that the > > > only existing way around this would be to make your managed bean have > > > session scope. Would you consider volatile to mean data that can > > > change at some point during the session? A session can go on for > > > hours if a user is active enough. > > > > > > I am glad that you agree that the feature should be added. Maybe I > > > can convince you that is more useful than you think ... Or maybe you > > > can convince me of another way to solve the problem? I've only > > > recently started thinking about this problem so maybe there is another > > > solution out there. If so, I am definitely interested to know what it > > > would be. This enhancement may seem like overkill but I can't think > > > of any other way around the problem. > > > > > > I strongly suspect that this is one of the reasons that <x:saveState> > > > was created (although we'd have to check with the creators of > > > saveState to be sure.) > > > > > > > -Heath Borders-Wing > > > > > > sean > > > > > > > > > -- > > -Heath Borders-Wing > > [EMAIL PROTECTED] > > >
