There are some cases where we can't cleanly figure out how to undo a change - in complex batches, there can be dependencies between the changes (i.e. create a new object, add a reference to it from some association). I think that generally though, we try to merge changes on the client where appropriate and when we detect that a change has become a noop we eliminate that message and the "commitRequired" flag goes back to false. We use hashtables to make this efficient.
I'm not sure why this particular case is not working... if you turn on server debug logging for the "Message.*" target, and you press commit when it is in this funky state, do you get a message being sent to the server? What does that message look like? Jeff ________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Dimitrios Gianninas Sent: Thursday, February 08, 2007 6:22 AM To: [email protected] Subject: RE: [flexcoders] FDS commitRequired and 2 way binding Actually I think that is correct behaviour, once a user starts to change any data a commit is required. Flex can't start looking at the original object and doing comparisons all the time, that would not be very efficient, especially if your object graph is big. Dimitrios Gianninas RIA Developer Optimal Payments Inc. ________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Rovira Sent: Thursday, February 08, 2007 6:03 AM To: [email protected] Subject: [flexcoders] FDS commitRequired and 2 way binding Hi, I was having some problems with the "commitRequired" property in the dataservice component when use 2 way binding. All works well until you have nested items. If you have a "UserVO" and an "AddressVO" inside the user. For example: <mx:TextInput id="name_address" text="{model.selectedUser.address.name_address}"/> <mx:Binding source="name_address.text" destination="model.selectedUser.address.name_address "/> Would make the "commitRequired" change from false to true as you expect. BUT, if it never change again to false if you turn back "name_address" to the old value. If you begin with name_address = "abc" and you change to "abcd" then all is ok (commitRequired = true). Now if you change back to "abc", commitRequired should change again to false since there's no changes pending. This is due to the fact that we have a nested object and databinding needs to know about a full object change (assign a new address object to the property... with plain properties all works well. Someone is using some technique to solve this problem? -- ::| Carlos Rovira ::| http://www.carlosrovira.com <http://www.carlosrovira.com> ::| http://www.madeinflex.com <http://www.madeinflex.com> AVIS IMPORTANT WARNING Ce message électronique et ses pièces jointes peuvent contenir des renseignements confidentiels, exclusifs ou légalement privilégiés destinés au seul usage du destinataire visé. L'expéditeur original ne renonce à aucun privilège ou à aucun autre droit si le présent message a été transmis involontairement ou s'il est retransmis sans son autorisation. Si vous n'êtes pas le destinataire visé du présent message ou si vous l'avez reçu par erreur, veuillez cesser immédiatement de le lire et le supprimer, ainsi que toutes ses pièces jointes, de votre système. La lecture, la distribution, la copie ou tout autre usage du présent message ou de ses pièces jointes par des personnes autres que le destinataire visé ne sont pas autorisés et pourraient être illégaux. Si vous avez reçu ce courrier électronique par erreur, veuillez en aviser l'expéditeur. This electronic message and its attachments may contain confidential, proprietary or legally privileged information, which is solely for the use of the intended recipient. No privilege or other rights are waived by any unintended transmission or unauthorized retransmission of this message. If you are not the intended recipient of this message, or if you have received it in error, you should immediately stop reading this message and delete it and all attachments from your system. The reading, distribution, copying or other use of this message or its attachments by unintended recipients is unauthorized and may be unlawful. If you have received this e-mail in error, please notify the sender.
