Hello @aliabdulla!
The best way to achieve this is by using the own grid logic to ensure it works the way you need it.
This is how marking the grid like that works:
- the initial value is X
- you set the value to anything different than X
- the grid marks it as dirty and places the little red tip on the cell
- that specific cell then has the ability to be reject()
'ed or commit()
'ed.
How does that work? Internally, Ext JS keeps two layers of data. One with the original data you bound on load, and a second that is filled as values are changed. Whenever the value changes back to the original values (or is committed), the cell will show as unchanged.
This means that, in order to get all the cells marked as changed, it is needed to not only run a set()
call to all individual record+field pairs (effectively every cell in the grid), but also the value must be different.
Knowing that, I can think on a couple alternatives.
initial/unchanged data is fake defaults
You can initialize the grid with values unlikely chosen by the user (empty strings, very very old dates). Then run thru every cell setting the new values you want in a similar code to the one you set every record as dirty (but now, via rec.set("field", "value")
for every single field/value in the grid).
In this case, if you add any means to "undo" changes to the grid (reject changes), the user will be seeing all those default values and the grid showing as "not edited" (no "red tips" in the cells).
current actual data, but then make the programmatic changes
This could be useful if you are pre-filling a grid of changes to the user, probably not your case. In this case, just fill with the initial values then set up the changed fields (so potentially some cells won't read as dirty if they match original values). The field set up would be teh same as the alternative above. Just initial data changes. "Undoing" the changes will show the initial (and perhaps also valid) values to the user.
the dirty marks are used like a form validation
If you want to use the dirty status as a form validation, that is, the cell shows the red tip until the user enters valid data therein, then I believe it is a bad idea. You should instead write some logic to actually "Paint" the individual cells in DOM level, and then another logic to validate the records. So you call the validation on load and apply (say) a CSS class to the cell, "painting it as invalid" where it applies. Then as values are changed, have an edit event check if the "painting" should be removed. Then in some circumstances (like grid refreshes) the initial validation might run to ensure all invalid cells are still reflecting their state.
bottomline
So any of the three approaches above fits your scenario? Let us know if some do, and if you're still lost on how to proceed with them, we can provide more clues to what best suits your scenario. Unfortunately it is not that simple to just mark them as dirty without actually changing the data, as recurrent logic in the tree will just wipe out the markings.
Hope this helps!