Hi Chris,

I had the same use case and implemented using workflow rules.  The rule criteria was ‘Evaluate the rule when a record is created, and any time it’s edited to subsequently meet criteria’.

Irvin

This is a good idea, I’m going to change it to be an “Idea” status, we’ve considered publishing “before” events corresponding to each of the “after” events that we currently publish, allowing you to intercept and modify the various requests that are made to Skuid Models and Components. 

Irvin - thanks for the idea, and yes workflow would work for some of my use cases.  Personally I dislike using workflow when the logic is tied to a Skuid page as it “hides” the logic, but function trumps elegance!

Zach - thanks for adding it to the ideas queue.  Not sure “before” makes sense on many of the events, but it would be awesome for save.

For now, I have a workaround for those interested.  I added a Page Title and my own Save/Cancel buttons (with appropriate JS to manage their state to represent when Save is acceptable, etc).  I then implemented by own Save and used skuid.events.publish to publish my own “before save” event, then called save on the model(s) I needed to be updated.  Then in my other code, where I needed to worry about a field changing, I used skuid.events.subscribe to be aware of the before save event and make my model changes.  This way, when the Skuidify team does add a before event, my code is already structured to accept it easily and just drop by own save/cancel buttons and publish event code.

- Chris

Zach - Yes please  Having before/after would be a welcome addition to Skuid!

Chris - Depending on your use case, you could use a custom button in the page title set to run multiple actions.  Using the action framework, you could trigger various activities that would occur before a save.  Then, you could handle the onerror of the save itself and “undo” if the save failed for some reason.  This doesn’t handle the use cases where save is initiated from somewhere other than a button.  There are some solutions for those scenarios but they involve a lot of coordination and custom code.  Having the “before save” event would cover the spectrum of possibilities.