Class SavedViewTableCustomizer

java.lang.Object
com.kingsrook.qqq.backend.core.model.savedviews.SavedViewTableCustomizer
All Implemented Interfaces:
TableCustomizerInterface
public class SavedViewTableCustomizer extends Object implements TableCustomizerInterface

  • Constructor Details

    • SavedViewTableCustomizer

      public SavedViewTableCustomizer()

  • Method Details

    • preUpdate

      public List<QRecord> preUpdate(UpdateInput updateInput, List<QRecord> records, boolean isPreview, Optional<List<QRecord>> oldRecordList) throws QException
      Description copied from interface: TableCustomizerInterface
      custom actions before an update takes place. It's important for implementations to be aware of the isPreview field, which is set to true when the code is running to give users advice, e.g., on a review screen - vs. being false when the action is ACTUALLY happening. So, if you're doing things like storing data, you don't want to do that if isPreview is true!! General implementation would be, to iterate over the records (the inputs to the update action), and look at their values: - possibly adding Errors (`addError`) or Warnings (`addWarning`) to the records - possibly manipulating values (`setValue`) - possibly throwing an exception - if you really don't want the update operation to continue. - doing "whatever else" you may want to do. - returning the list of records (can be the input list) that you want to go on to the backend implementation class. Note, "old records" (e.g., with values freshly fetched from the backend) will be available (if the backend supports it)
      Specified by:
      preUpdate in interface TableCustomizerInterface
      Throws:
      QException

    • preDelete

      public List<QRecord> preDelete(DeleteInput deleteInput, List<QRecord> records, boolean isPreview) throws QException
      Description copied from interface: TableCustomizerInterface
      Custom actions before a delete takes place. It's important for implementations to be aware of the isPreview param, which is set to true when the code is running to give users advice, e.g., on a review screen - vs. being false when the action is ACTUALLY happening. So, if you're doing things like storing data, you don't want to do that if isPreview is true!! General implementation would be, to iterate over the records (which the DeleteAction would look up based on the inputs to the delete action), and look at their values: - possibly adding Errors (`addError`) or Warnings (`addWarning`) to the records - possibly throwing an exception - if you really don't want the delete operation to continue. - doing "whatever else" you may want to do. - returning the list of records (can be the input list) - this is how errors and warnings are propagated to the DeleteAction. Note that any records with an error will NOT proceed to the backend's delete interface - but those with warnings will.
      Specified by:
      preDelete in interface TableCustomizerInterface
      Throws:
      QException