close

Filter

loading table of contents...

Studio Developer Manual / Version 2010

Table Of Contents

5.3.3 Issues

CoreMedia 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 7.17.1.4, “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 com.coremedia.ui.data.validation.Issues 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 document - you could set up a validator to raise a WARNING when a document 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 7.17.1, “Validators” for details.

Search Results

Table Of Contents