These are the most common and useful terms you will come across using the Nuxeo Platform. A fuller more extensive list can be found in the Nuxeo glossary.
Document
The Document is the main structure managed by the Nuxeo Platform. A document in the Nuxeo Platform is an object that holds system properties and custom properties. It goes far beyond the “file” concept. Inside the Nuxeo Platform, documents are files, folders, workspaces, cases, media, sections, assets, etc. They are all considered as documents. A document can hold files, pictures, videos or any binary or list of binaries.
Repository
The repository is the part of the Nuxeo Platform in charge of storing and serving the documents. It embeds a lot of logic to ensure the security and availability of the documents. We could make a parallel between a database and a repository. The repository organizes the documents in a hierarchy.
Property
Also sometimes referred to as metadata, properties are the granular elements of data stored on a document. There are different types of properties:
- text properties are strings;
- dates are stored as such;
- yes/no properties are booleans;
- numbered properties use integers;
- blobs are used to store binary content such as files.
Properties can also be a list of these types, such as a list of dates, a list of strings. They can even have a more complex structure (like a list of “contact”) and are then named “complex properties”.
Schema
A schema is a set of property definitions. For instance, the Nuxeo Platform uses the Dublin Core schema for most of its documents. A document that holds the Dublin Core schema has the following properties: a title, a description, a creation date, a modification date, an author, a subject, etc. The schema is a nice concept to enable property definition re-use on several document types.
Blob
Blob is a frequent term used in the Nuxeo Platform documentation. In a more end-user language, it is equivalent to a file, a binary content.
Document Type
A document type is the set of properties that define a document. A document type is defined by the list of its schemas, its lifecycle, the forms to present to the user or its versioning policy.
Life Cycle
The lifecycle of a document defines the states the document can be in. It also defines the possible paths, called transitions, to go from one state to another. The lifecycle is useful to say a case is “created”, “being_processed”, “processed”, “archived”.
Vocabulary
A vocabulary is a list of values stored in the Nuxeo Platform. Vocabularies are used to let the user choose the value of a document property among a controlled list of values. Power users and administrators can edit vocabularies from the Admin Center. There are simple vocabularies and hierarchical ones. The vocabulary term could be considered as similar to “Taxonomy”.
ACL
ACL stands for Access Control List. An ACL is a set of security rules defined on a document. It says for instance: For the Document D, the group G has the permission to Edit and the User U has the permission to read. In the Nuxeo Platform ACLs are inherited throughout the hierarchy of the repository. A rule defined at the top is then applied all the way down to the deepest documents of your repository.
NXQL
NXQL stands for Nuxeo Query Language. It is a SQL-like language used to query documents in a Nuxeo repository. NXQL allows for querying documents with their metadata as well as their full-text content.
Workflow Engine
The Nuxeo Platform embeds a workflow engine. This workflow engine knows how to read a workflow model. It starts a specific instance from the model, from the beginning to the end of the process execution. You should read the Workflow Model entry for a better understanding of the concept of workflow.
Workflow Model
A workflow model is an enterprise process digitized in the platform. Typical candidates to this digitization are documents validation, purchase orders, case processing, invoice management.
From a technical point of view, a workflow is an automated process that may involve human interactions. This process has a beginning, an end and a state persisted at any time between this beginning and this end. A workflow is represented by a graph of nodes. At each node the workflow designer specified what should happen. This is how the process is automated.
The workflow engine is in charge of taking a workflow model, instantiate it and run it all the way long from the beginning to the end. Workflow models are designed with Nuxeo Studio.
Node
A workflow node is a “step” of the workflow model. The node holds a set of configurable properties that define what the workflow engine should do at this step. For instance, it can create a task for someone, send some notifications, update some document properties.
Workflow Instance
A workflow instance is the instance of the execution of one given workflow model by the workflow engine. A workflow instance holds the data bound to a specific execution as well as the current state of execution. A workflow instance is composed of node instances, like the workflow model is composed of nodes.
Transition (Workflow)
In the workflow terminology, a transition is what links two nodes in the graph of a workflow model. A transition is always associated to a condition. When there is a transition between nodes n1 and n2, the workflow engine will check if the transition condition is evaluated to true. If yes, it will execute n2 immediately after n1 is processed.
Task
A task is a persisted object that represents what a workflow instance expects from a user or a group of users. They are expected to give some information through a form and click on a button (like Accept, Reject, Confirm, Notify, Transform, etc.). A task usually has one or several assignees, a title, a directive and an expected date of achievement. A task is either to be done or done. A task is created by a node for which the property of task creation has been activated. The task assignees can be specified directly in the task definition or can be dynamically computed.
Layout
A layout is a definition of how data or UI components should be organized on the screen, in terms of “position”. A layout is organized either as a table or as a “grid”. Layouts are used for specifying
- how the content of a tab in the UI should be displayed;
- how the fields of a form should be displayed;
- how the fields of a search result or any document query should be displayed too.
A layout defines the position of widgets. Layouts are defined using Nuxeo Studio.
Widget
A widget is an element of UI that can be displayed via the layout system. A widget can have a varying complexity. They can be used to display a static text, to pickup values in a list or, for the most complex ones, to display a full form or list of data. The list of existing widgets in the Nuxeo Platform can be extended by creating your own custom widgets.
Tab
A tab in the Nuxeo Platform is a view displayed on a document, controlled by a filter. It is a UI pattern used for presenting information and user actions related to one concept on the document. On the same document users with different profiles will have access to different tabs. And so they will be presented different forms and buttons that correspond to their profile.
Content View
A content view is a list of data that comes from the repository. Most of the time, it is a list of documents, but it can also be a list of vocabularies or a list of audit entries. A content view is composed of
- a query,
- an optional filter,
- a result layout that defines which columns of value are displayed,
- many options that determine whether the list is selectable, exportable, paginated and more.
We could say it is a list of data and the way to display it.
Nuxeo Studio allows to configure content views.
Action
Historically, actions (and user actions in Nuxeo Studio) were a mean to add a link, a tab or a button in the user interface in a declarative way. It’s a great way of making the platform modular, since you can add a new button in the user interface afterwards, in your own plug-in. The notion of action comes with the notion of filter, that allows to control when the element should appear.
The use of the action pattern has been extended in the platform. Technically, the action framework can now be assimilated to a system that enables to inject typed UI components in the back office declaratively.
Nuxeo Studio allows to declare user actions. You can also use XML contributions for more advanced use cases.
Component
A component is a set of code and all kind of software instructions deployed on your Nuxeo Platform application. This Nuxeo Runtime term is inspired by the OSGi specification.
Plug-In
A plug-in is a JAR (Java packaging) that contains none to several components and resources that are deployed on the Nuxeo Application.