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
Parents

  • 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");

Comment

  • 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");

Children
No Data