Live Applications provide an API (view model + methods) for specific business cases.
All live applications are implemented in the Back End (Java), so all operations and calculations are made on server side.

Command Handler

  • Applications are declared in a workspace for asset pages
  • For each page provided only 1 instance of each type of page application is declared
  • All applications which are declared on an asset page are available for all widgets on that page
  • Every application provides a specific View Model implemented in the application
  • Every application provides methods implemented in the application
  • Applications notify the client about changes/updates in the View Model and the available methods

Getting updates from Application

pageInstance.getContextProvider().then(
    function (contextProvider) {
        if (contextProvider && angular.isFunction(contextProvider.getLiveApplicationInstance)) {
            applicationReader = contextProvider.getLiveApplicationInstanc ("com.censhare.api.applications.asset.metadata.AssetInfoApplication");
 
            if (applicationReader) {
                applicationReader.registerChangeListenerAndFire(handleUpdate,$scope);
            }
        }
    }
);
 
function handleUpdate(updateData) {
    if (updateData.version === currentVersion) {
        return;
    }
 
    data = updateData.data;
    methods = updateData.methods;
    ...
 }

  • applicationReader - Instance of the csReader
  • updateData.version - The version of the update. It’s recommended to check if there are changes in update;
  • updateData.data - Contains the View Model of the application
  • updateData.methods- Contains the application Methods, which are available in the current update

Calling Application methods

Example 1

if (methods.checkout) {
    return methods.checkout().then(
        function (data) {
            return openNewDialog(data);
        },
        function (error) {
            csNotify.warn('Edit Metadata', 'Checkout asset failed', error);
        }
    );
}

Example 2

methods.callRenderer({documentId: $scope.dataHolder.doc.id}).then(
    function (data) {
        ...
    },
    function handleError() {
        ...
    }
);

  • All methods return a promise
  • The input parameter can be passed to the method
  • The data.result.data contains the output parameter if there is one
  • If the model was modified by a method call, the client will receive an update
  • A method promise is rejected now when there is a data.result.errorCode. No need to check it now in the success function
  • Good practice: check if the method exists before the call
  • Every application provides default application methods:
    • checkout() - Available when the user is allowed to checkout an asset and the asset is not checked out
    • checkin() - Available when an asset is checked out
    • abortCheckout() - Available when a user is allowed to abort checkout and the asset is checked out
  • If the application method is called and it’s currently processing, then it’s in progress (a method promise was not rejected or resolved), other methods are not available.

Advantages and disadvantages

(plus)

  • Easy way to operate with asset and dependent assets
  • Sharing one instance of application between all page widgets
  • Provides a dedicated View Model
  • Allows to get updates for opened and dependent assets
  • Provides a built-in functionality regarding the check-out / check-in state handling (required for all editor pages)

(minus)

  • It should be added to the workspace manually
  • All applications are alive while the pageInstance is alive. When alot pages are open then many applications will stay in the memory
  • There is no possibility to prepare the View Model object for the item-renderer. Additional asset queries must be executed by the Front-End
  • Back-End development required