Searching for some explaination here... First and foremost don't take what I've said here as set in stone advice.... It's how I think things work...
I have a grid that provides some CRUD operations and need to implement the synchronization between the datastore and the actual database. Digging through the code this is what I have found.
First off I can retrieve the currently selected/being edited Record by
Record provides a number of functions to manipulate the in-memory record and also maintains state, meaning that it knows what has been modified while you are editing a record.
After getting the record above we can now beginEdit'ng. This lets the class know that we are now editing a record and to please record any changes/modifications that are made.
We can now use the .set(name, value) method to update each individual field in our record.
Please note that set is intelligent enough to know if we passed the same value as the old value. If all fields were set to exactly the same thing as what they were before the record will not be marked as dirty/modified.
After editing our record we can now call the function endEdit
If the record is dirty (has been modified) it will call the function afterEdit in the associated store.
store.afterEdit looks for the record in the stores modified property, if it's not there it puts it there. It then fires the update event with a scope of this and an argument of the current record.
Therefore we can now setup an event listener to handle the update event of the datastore.
The clarifications I need if all of the above is true:
- How can the data store possibly determine that this record has been finished/committed? data.store.modified is never cleared
- The reject function sets the dirty flag to false.... however there is no way to 'rollback' aside from retrieving the data again from the server side because set directly modifies this.data in addition to modifying this.modified. This is OK behaviour but I just want to be sure this is how it works.
I have a grid that provides some CRUD operations and need to implement the synchronization between the datastore and the actual database. Digging through the code this is what I have found.
First off I can retrieve the currently selected/being edited Record by
var editRecord = sm.getSelected();
After getting the record above we can now beginEdit'ng. This lets the class know that we are now editing a record and to please record any changes/modifications that are made.
editRecord.beginEdit();
editRecord.set('fieldA', 'myValue'); editRecord.set('fieldB', 'my other value');
After editing our record we can now call the function endEdit
editRecord.endEdit();
store.afterEdit looks for the record in the stores modified property, if it's not there it puts it there. It then fires the update event with a scope of this and an argument of the current record.
Therefore we can now setup an event listener to handle the update event of the datastore.
store.on('update', function(currRecord) { //make ajax update to my server side //onSuccess call currRecord.commit(); //onFailure call currRecord.reject(); }
The clarifications I need if all of the above is true:
- How can the data store possibly determine that this record has been finished/committed? data.store.modified is never cleared
- The reject function sets the dirty flag to false.... however there is no way to 'rollback' aside from retrieving the data again from the server side because set directly modifies this.data in addition to modifying this.modified. This is OK behaviour but I just want to be sure this is how it works.

#2
![]() |
![]() Everything you said is correct.
My recommendation is not to use that stuff yet. It is part of the auto-saving functionality that isn't complete. I actually did some updates on it a little while ago but it hasn't been deployed (needs some testing). I will let you know when I deploy it. - How can the data store possibly determine that this record has been finished/committed? data.store.modified is never cleared You can clear it at any time. store.modified = []; When all the saving stuff is complete, I'm sure the "save()" function will do it for you automatically. - The reject function sets the dirty flag to false.... however there is no way to 'rollback' aside from retrieving the data again from the server side because set directly modifies this.data in addition to modifying this.modified. This is OK behaviour but I just want to be sure this is how it works. reject was completely wrong. commit was actually reject. ![]() The way a record can be rolled back is because it store the old values in modified. modified contains the original value of the field, and data contains the temp value. So to reject, you would copy the old values back into the live data. Make sense? On a side note, it's nice to see people digging into the source! ![]() |
#3
![]() |
![]() I deployed the fixed functions in Rev 8. Feel free to try them out and let me know what kind of results you get.
![]() ![]() |
#4
![]() |
![]() Thanks Jack; I was expecting the fixed functions to take a lot longer than 22 minutes!!
Do you still hold your recommendation not to use this stuff, until the auto marshalling stuff is done? Do you have any sense of time for when that will be? Alpha? Beta? Stable? I am trying to put together a demo to show that it would not be that difficult for my team to purchase/implement ext in our applications. On a side note, the variable name modified seems very backwards to me! ![]() |