Studio Developer Manual / Version 2310
Table Of ContentsCoreMedia Studio has built-in support for server-side validation of content objects. You can leverage the validation framework for your own (non CMS) data resources, but for content objects managed in the CoreMedia Content Server, the framework already offers convenient support (see Section 5.4.2, “Content” for a general description of the Studio Content API.)
Server-side validation always works on values already saved (persisted) - in other words, a
validator will never prevent the user from saving data, so that the risk of data loss is
minimal. You can however set up Studio to prevent the
user from approving or checking in documents that have validation issues with severity
ERROR (see Section 9.21.1.5, “Tying Document Validation to Editor Actions” for details on how to
configure this).
The client can ask the server to compute issues of an
entity (most commonly Content), where they become accessible as a
@coremedia/studio-client.client-core/data/validation/Issue object. Once received, the client can
do things like highlight a property field that contains an invalid value, or open a dialog.
Studio offers built-in support for marking standard
property fields invalid, and offers the user a convenient interface to step through and
correct detected validation issues in one go.
The issues object provides access to individual Issue objects through a number
of methods:
getAll()returns all issues of the entity in a single array.getByProperty()returns a sub bean whose properties match the properties of the entity. Each property contains an array of issues that affect exactly that property.getGlobal()returns an array of issues that do not affect a specific property, but that describe the state of the entity as a whole. A common example for this is a validator that checks for the correct folder path of a content item - you could set up a validator to raise aWARNINGwhen a content item is created in a folder that is not appropriate for its type, for example.
An issue links back to its entity by means of the entity property. The
severity property indicates a level of "INFO",
"WARN", and "ERROR". You can freely define the
severity level for any validator. An issue may belong to one or more categories. Issues are grouped according
to their category when displayed in the client.
The property property stores the name of the property whose value causes the
issue. If null, this indicates a global issue that affects the entity as a
whole, rather than one of its properties. In the property code, each issue
stores a string identifier indicating the type of issue detected. Applications are expected
to localize this identifier as needed. Depending on the code, the array property
arguments might store additional data in a specific layout.
The issue code identifiers depend on the type of entity that has been validated. In fact, each server-side validator may introduce its own code and you have to refer to the documentation of the validators for details. Some validators allow you to configure the error code that they report. In custom validators, you can also pass on additional ("runtime") information describing the error in more detail, and use this additional information to present user-friendly descriptions of the problem in the UI. See Section 9.21.1, “Validators” for details.
