Package com.smartgwt.client.widgets.calendar.events

# Interface HasEventSaveErrorHandlers

All Superinterfaces:
  `HasHandlers`

All Known Implementing Classes:
  `Calendar`, `Timeline`

public interface HasEventSaveErrorHandlers extends HasHandlers

- ## Method Summary

  Modifier and Type
  Method
  Description
  `HandlerRegistration`
  `addEventSaveErrorHandler(EventSaveErrorHandler handler)`
  Notification method fired when an attempt to save `an event` following edits or drag-movements results in an error from the server.

  ### Methods inherited from interface com.google.gwt.event.shared.HasHandlers

  `fireEvent`

- ## Method Details

  - ### addEventSaveErrorHandler

    HandlerRegistration addEventSaveErrorHandler(EventSaveErrorHandler handler)
    Notification method fired when an attempt to save `an event` following edits or drag-movements results in an error from the server. May be overridden to handle specific errors and provide feedback to the user or push a server-provided record to client caches with a call to `updateCaches()`, for example.

    The `scenarioCode` parameter may be used to determine `how the save was initiated`.

    Return false from this method to cancel builtin behavior, which is as follows:

    If a save happened because an event-canvas was moved or sized with the mouse, and any kind of error occurs, the event is restored to it's pre-save position - if this method specifically returns true, the errors are also sent to `central error handling`, which will show them to the user in a simple error dialog.

    If a save happened because an event was edited in the `eventDialog` or `eventEditor` windows and a validation error occurs, the window is re-opened for editing with the validation errors visible. If any other kind of error occurs, the window will not be re-opened and, if this method specifically returns true, the error will be sent to `central error handling` which will show a simple error dialog to the end user.

    In all cases, if the server returned an updated record despite the save failing (eg, perhaps the server enforces optimistic locking and the underlying record has been changed by another user), it is assumed to be a latest-version of the record and is applied instead of the original record during those builtin UI processes. So, the `eventEditor` and `eventDialog` will show any changes from the latest-record. If the save was caused by dragging an event and the event's `start` or `end` dates are different in the latest-record, the EventCanvas will be positioned using the latest values, instead of returning to it's pre-save position on-screen.

    Parameters:
      `handler` - the eventSaveError handler
    Returns:
      `HandlerRegistration` used to remove this handler