I'm also curious if anyone finds the behavior of the Data Management awkward. In the current model, there is only one visible representation of each managed item on the client. It is "the" managed instance of that object. It tracks both uncommitted changes on the client as well as changes made to that object on the server (if you have sync mode enabled). When you commit these changes, they are applied to the server. If that transaction fails, an error is reported. The changes are not automatically reverted at this point - they are just moved back into the uncommitted list. You probably are explicitly calling "revertChanges" to undo the problematic changes.
When you call "createItem", it queues a change to create this item which is sent to the server only when you commit. When that changes is committed, you can auto-refresh any collections that might include that item. Those queries are updated automatically to include that item and at that point those changes are pushed back to client so the newly create item may appear in managed collections. This is why it seems like DM does not track changes until you commit... only the server knows which collections that item belongs in. If the client programmer knows which collections this item belongs in, you can put them in there locally on the client simply by adding them to the managed array collection. After the commit, this change is sync'd with where the server thinks that item actually belongs (i.e. if the server does not want that item there, it will revert the change you made on the client, if it agrees, no change is made). I think for most use cases, this creates a pretty manageable way to deal with your data on the client. If you want to make a copy so you can isolate changes, you can use the ObjectUtil.copy utility to create a copy of that object but you do still have to apply these changes to the managed instance before you commit. It would not be that hard to add a new mode so that changes you make are placed into a separate copy of the managed instance until you commit successfully. Let's say you had a form to edit an item, and another control displaying the current version of the database copy of that item. This mode would allow that view to remain displaying the current version in the database until it commits successfully. It sounds like this is the kind of approach you are looking for? Does anyone else think that would be useful? Jeff ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of fermartel Sent: Friday, April 13, 2007 10:56 AM To: [EMAIL PROTECTED] Subject: [flexcoders] FDS There is something about FDS which has always seemed a bit ackward to me. This is the fact that one must first make changes to the FDS managed collection to be able to commit these changes. This in itself is fine, but this means that if I have a grid which displays the managed collection, the user must first modify this data and commit the changes to then see the changes revert back to the original values if the transaction failed. (This does not hold true for createItem(), because for some reason yet unknown to me, when one calls this method, it does not reflect on the managed collection...any ideas as to why?). So the user sees the data displayed change, but on error, it sees it change back. To me, it would seem more logical to see the data displayed change only if the transaction was succesful. Maybe this is because I am used to RemoteObject, which calls the service, and on "result" is where one does the actual modification to the data displayed, not before. Does anyone else find this as a strange flow of events? Or are there any ways around this? One could make a temporary managed collection with the same exact data as the displayed collection, and make changes to this collection, commit them, and if successful, then make the same changes to the displayed collection. This way the user would only see the data displayed change if the commit was successful. But this seems much more trouble than its worth. Any ideas or suggestions would be appreciated. Thank you!
