1

I have had this requirement way too many times where only modified rows of records (aka dirty records) in a VF table should be saved. What is best practice for detecting modified fields (and subsequently SObject records) on a VF page?

I have tried caching the old instance of the records and then comparing it with the new instance but this won't work when dependent picklists or Record Types are present. I feel like there must be a best practice/pattern for doing this in SF but my search hasn't yielded anything.

Improve this question
4
  • So what's your question ? What exactly are you struggling with ? Please understand that we need to understand what you've tried, and what is not working for you to be able to help you out here. What are dirty rows ? What where the solutions you tried ? Why didn't you like them ? If we're not aware of those details, how can we answer any alternative ?
    – Samuel De Rycke
    Commented Apr 22, 2015 at 7:51
  • What do you mean by Dirty Rows? What are the issue you are facing?
    – RajeshShah
    Commented Apr 22, 2015 at 7:53
  • My bad. Late night. Updated.
    – Mossi
    Commented Apr 22, 2015 at 8:23
  • Have you considered client side triggered save on cursor/focus leaving of your table cell, or having a "save" button on each row ?
    – Samuel De Rycke
    Commented Apr 22, 2015 at 8:28

1 Answer 1

Reset to default
0

If I understand correctly, you build a VisualForce page and put a table in it and you want to figure out how to handle user changes that occur in the table you laid out for them on that page?

If so, I would look in to various action parameters that are available on most apex tags: (the following are specific to and )

  • onclick
  • ondblclick
  • onkeydown
  • onkeypress
  • onkeyup
  • onmousedown
  • onmousemove
  • onmouseout
  • onmouseover
  • onmouseup
  • onRowClick
  • onRowDblClick
  • onRowMouseDown
  • onRowMouseMove
  • onRowMouseOut
  • onRowMouseOver
  • onRowMouseUp

With these, you could use JavaScript to save values when the user clicks on a cell or row and then check for value changes after the user clicks elsewhere. This essentially keeps things as micro-transactions on change detection (instead of saving the whole table and doing a sweep for changes).

Not sure if it is "best practice" but it is an idea.

Improve this answer
2
  • It's not as simple as using these events. What if the user types in a value and then deletes it? The logic needs to somehow remember the initial value. Using JS is definitely one possible solution but that means a critical part of the logic has to now run on the client-side -which translates to a broken MVC pattern.
    – Mossi
    Commented Apr 23, 2015 at 0:41
  • Right, so when the user clicks on the field, that's when you remember the value. If they change it and leave the field, you check to see if the value changed. If it did, then you have some logic to do and if it didn't (i.e. "they type a value and then delete it") then you have some other logic to do. Whether you choose to allow deletions to save as an actual removal or default to restoring the original value is up to you and your requirements.
    – JeffyB
    Commented Apr 23, 2015 at 14:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .