Skip to end of metadata
Go to start of metadata


The current dirty fields implementation (third party jQuery plugin) has many issues currently. Among this is the lose of dirty field information (when a refresh is done the dirty class is lost). Therefore the KRAD team has decided to roll our own dirty fields plugin for resolving these issues.


Essentially the design will be to track change events on all form data and add a dirty flag to jQuery data. Since this will be managed in memory and not the DOM, dirty information will not be lost with refresh events. (Tech Question: Can we bind a handler to the form onchange, and detach the handler once the dirty flag is set to true until it is set to false again? Might help performance. Note the current plugin checks the blur event and actually compares the new value to the initial form value.)

As is done in the current plugin, we will then need to create handlers to catch when the user is trying to leave the page (excluding the view actions) and give the dirty notification.

For view actions, the dirty flag will be sent as a request parameter. This will then populate a dirty flag on the form object which will then be written out as a hidden with the response. Script will then read the hidden to reinitialize the dirty flag in memory. 

Since the dirty property exists on the form, application logic can be added to set and clear the flag. For example for a save action where the form data is persisted, the flag can be set to false to clear the dirty indicator. We can also introduce an action property to automatically clear the dirty flag.

Finally, since the dirty flag will be sent with requests and reinitialized, this will carry through the dirty flag across full view rendering (non-ajax calls).

New Design

There are problems with the above, I have no way to detect the following:
The fields dirty state separately from the flag being passed around.  This is a problem because I don't have any real way to determine this with only a true/false flag, if I set the flag to true when a field is dirty (which is not what we want to do) I would pass it forward and I would be required to reset it all over the place - this should be controlled on the client.

New proposal -

dirty flag for server control
dirty count for client control

In this way I can keep track of changes made on the client and not have to worry about what the flag is.  I the flag has been set to true by the server, obviously the form will always be dirty when we check, but if not then if the dirty count > 0 the form will be dirty.  If both conditions are false, the form is not dirty and we can leave the page without messaging. 

Dirty count would be incremented when a user changes the field value from what it was originally or the special case of adding or deleting a line (on click script would handle this).  It would be decremented if the user could change it back to the original value (not possible in add/delete case).  On a successful page change this would be changed back to 0, but could also be cleared with javascript function call.

Alternatively, if the user performs an action that performs a server-side roundtrip and they need to make the form dirty in response to some server action performed they would have the form variable to set dirty to true.  This would then be set on the hidden that is passed around called dirtyForm.  Until this is explicitly set to false through a server call or through a javascript function call, the form would continue to be dirty.  My assumption would to always to turn this off on a navigate call (server side) or save call (client side), but beyond that it would be up to the developer.

  • No labels


  1. The answer to your technical question is yes, we can unbind when we receive the first event that causes dirtyness

  2. Also we should add custom eventing for firing dirty check and dirty marking (probably)