Backoffice Framework Module Implementation

Backoffice Framework is composed of building blocks of different shape and functionality. By putting them together, you can build different applications with the set of functionalities. These building blocks are widgets.

Actions are special components provided by the Backoffice Framework that you can use inside your widgets.

Editors are special components provided by the Backoffice Framework that you can use inside your widgets in order to edit and manipulate data.

The best way to familiarize with any topic is to learn by practice. The following sections help you learn everything about developing a widget and orchestrating your Backoffice application.

Learn how to integrate the AngularJs library with Backoffice Framework.

Learn how to configure the drag and drop functionality in Backoffice Framework.

By default, the Advanced Search widget allows to use a single global operator when defining a search query. However, with the enhanced Advanced Backoffice Framework Search API, it is possible to set multiple conditions for search.

Backoffice Framework provides generic widgets for working with data, including the ability to perform CRUD operations, modify permissions, and run searches. Examples of such widgets include Editor Area, List View, and Text Search. These widgets are independent from the underlying platform through their use of the Cockpit Data Integration abstraction layer.

All CockpitNG POJO classes that are used for widget communication are able to serialize to JSON. Additionally, Backoffice provides object mapper configuration for platform model classes - the classes which extend ItemModel.

While the user customizes the existing features or writes new features, there is often a need to modify a bean definition. In many cases, a common spring aliasing override is not enough. For such cases, the extenders mechanism has been introduced. Each one of the extenders is capable of amending any spring bean that is defined in the same, or in any, of parent spring contexts.

Error messages displayed to users after a failed operation or interaction that is causing an exception, are a cross-cutting concern and therefore have been unified in the Backoffice. There is a mechanism for converting exceptions into their textual representation.

For the custom Backoffice extensions, there might be a requirement to extend the Backoffice web.xml file by adding a filter or a servlet. Backoffice supports modularity of the web.xml through the web-fragment.xml to fulfill this need. This allows every Backoffice application to use own filters and servlets.

Backoffice Framework utilizes property accessors and method resolvers in the classification system.

There is a mechanism to translate Platform application events into cockpit events, so that they can be handled by cockpit event queue. This solution allows you to hook into an application event in your Backoffice application, like for instance you can make one of your widgets aware of a session that a user changes.

Backoffice provides support for Syntactically Awesome Style Sheets (Sass) scripting language, a CSS preprocessor that gives better experience in styling your application.

The widget model is a place, where you should hold all data that define the state of your widget.

You can use additional settings in the local.properties or project.properties files that change the default behavior of Backoffice application.

Learn how to configure the UI of the Backoffice Framework application.

The widgets.xml file keeps the application default configuration. It is loaded on the Web application startup.

In multi-tenant configuration of Platform, Backoffice requires additional configuration to avoid clash of resources.

ZK Framework technology is used to build up Backoffice Framework components. Backoffice Framework provides you with a mechanism to change the default settings of ZK Library in your project.

You can fetch classification metadata using the OData REST endpoints.