Under Community Review

Most of this functionality is possible through the Event System, AppData, the Custom URL JavaScript, and XSD constraints (as well as GUI extensions). However, not everything is exposed through the Schema form view and there isn't an explicit approach to re-using and managing such messages and logic.

We'll leave this open under community review to see how the community reacts to the idea. We'd also be interested in seeing how editors reacted to existing extensions or follow-up implementation based on these or other examples:

Constraints Schema Type that can be applied to fields

This is inspired by Neil Gibbons' request for constraints fields in a schema. Neil's issue was two-fold:

  1. Separate minOccurs from mandatory
  2. Provide an accessible point in the UI for setting this. 

While I like this idea, I think that a limitation here is error messaging: What happens if a user does something that violates the constraint? What if I need a custom constraint (like disallowing certain characters, applying a character count)? Today it's possible to apply that constraint, but I can't add user-friendly messaging to it. 

I'd like to propose that we have a new schema type, called "constraint". The Contraints schema would allow me to apply the following kinds of constraints -- with accompanied error messaging:

  • minOccurs : n minimum instances of field
  • maxOccurs : n maximum instances of field
  • minLength : n minimum characters allowed in field
  • maxLength : n maximum characters allowed in field
  • Mandatory:  boolean that indicates that the field must have a value
  • Pattern : Regex that indicates what strings are allowed as a value
  • Logic [and, or, not()] : Sets the Mandatory flag to true when there are fieldnames matching the right-hand side of the operator (or argument) are present and pass their own constraints

And again, each constraint within the schema has an accompanying error message. 

90% of the time, I can get by without this. But the other 10%, I can't use Tridion unless it's got this. 

frank taylor

  • Reuse: The idea of a separate schema is entirely about re-use. Any re-usable setting -- field level, or otherwise, would work.

    Messages with constraints: I would want the messages to live with the constraint definition. Each individual constraint definition would be able to have an error message:

    Pattern: [A-Z0-9]; message: "you can only use uppercase letters and numbers"

    And sure, I would think that depending on the field, there might be additional constraints (e.g. Establishing with numbers whether they are floats, ints, etc)

    Additional Messages: And I know min, max, and mandatory are enforced by the UI (except minimum is __also__ mandatory). But it would be nice to have the option to have messaging for any constraint (if we wanted it).

    Logic examples:

    All of these have a simple goal of making a field required only under certain conditions. It would be nice if the field were grayed out or even hidden unless the conditions were met. And the condition is "met" where the referenced field passes constraints/validations.

    Field "foo" is required only if field "bar" is filled out:

    Applied to field "foo"

    Logic: and("bar");

    Field "baz" is required, only if fields "foo" and "bar" are filled out:

    applied to field "baz"

    Logic: and("foo","bar");

    Either field "foo" or field "bar" is required, but not both:

    Applied to field "foo"

    Logic: or("bar");

    Applied to field "bar":

    Logic: or("foo");

    Field "baz" should be un-required / hidden if field "foo" is filled out:

    applied to field "baz"

    Logic: not("foo");

  • Could you provide some examples of the logic idea?

    Is the idea of a separate schema type about re-use? Would it be enough that such settings were still at the field level or otherweise re-usable (without being a schema)?

    Things to consider are whether such messages would live with the constraint definitions or in the selection of those definitions. Also different constraints apply to different types of fields (so this might suggest a separate type of definition for plain text validation, versus a multi-value field, etc.).

    Also, a few constraints are currently enforced in the UI such as minimum, maximum, and mandatory. For example, users can't save without entering a value for a mandatory field, which is denoted by a red astrisk. They can't have less than the minimum nor add more than the maximum (for multivalue fields). Would these need additional error messages?

    Perhaps this idea could focus on the pattern and/or logic parts to make it more distinct from the multiple values check box in schema idea.