Mastering Data Modeling with Liferay Objects

Course Overview

Validating Data Fields

Data validation is a critical step in ensuring the integrity and accuracy of information entered by users. Without validation, data inconsistencies and errors can accumulate, leading to problems like incorrect reporting, malfunctioning workflows, and diminished user trust. By incorporating robust validations at both the field and object levels, administrators can ensure that the data stored aligns with expected formats, conditions, and business rules. Thoughtfully planning validation methods also helps improve the overall user experience by reducing errors during data entry and enforcing business logic that guides the user through expected patterns.

Now that Clarity has a better understanding of the types of fields they can implement in their data models, they want to make sure that Liferay’s validations are robust enough to scale with a rapidly growing enterprise. Here you’ll learn about the various ways you can validate data in Liferay.

Field Configurations

Field configurations apply specific rules to individual fields within an object or form. They ensure that each piece of data entered meets predefined criteria before it is saved. By controlling input at this granular level, you can maintain consistency, accuracy, and security within your data set.

For example, you might need to make certain fields mandatory, unique, or restricted to a specific length. Field configurations act as the first line of defense against invalid data entry, preventing common mistakes that could otherwise degrade the quality of the database. When designing these configurations, it's important to balance user experience with the need for data integrity—overly strict configurations rules can frustrate users, while lenient rules may lead to incomplete or unreliable data.

Mandatory Fields

Mandatory fields require critical user input for submission. You should only make fields mandatory if they are essential for the current stage of data entry. For instance, in a ticketing system, while it’s important to make the "Issue Description" field mandatory at the time of ticket creation, other fields like "Resolution Details" should be optional until later stages.

If a field becomes mandatory depending on the value of another field, you should use the “Expression Builder” object validation instead.

Unique Fields

Ensuring uniqueness within fields like usernames, ticket numbers, or email addresses prevents conflicts and duplication of key data. This is especially critical for fields used as identifiers.

Both text and integer fields can be unique. For text fields, be aware that the validation is case-sensitive. For example, “Ticket” and “ticket” are two different values that do not violate the uniqueness rule.

Later in this lesson you’ll learn about composite keys, which you can use to limit the scope of uniqueness checks to subsets of applicable data. For example, you can ensure that ticket numbers are unique within a specific project or department.

If you do configure a field to accept only unique values, it must always be mandatory as well. If the field is not mandatory, you are able to create an object with no value for that field. Because you are enforcing uniqueness, all subsequent object creations will fail if no value is provided for the field, effectively making the field mandatory anyway. To avoid confusing users in this scenario, make all unique fields mandatory.

Length-Restricted Fields

Limiting the length of text and long text fields prevents excessively large inputs that could affect both storage and user experience. For example, limiting the length of a comment or description field can enhance readability and prevent database strain. This validation is also useful when you are integrating with external systems (especially legacy systems) that have more restrictive field lengths.

Read-Only Fields

Some use cases require fields to remain immutable after data entry or under specific conditions. Setting fields to read-only is useful for maintaining data integrity or preventing unauthorized changes. For example, a status field in a ticketing system may be set to read-only so that only administrators can change it using predefined actions. You might also lock the description of a ticket if it is In Progress or Closed, or if the current user is different from the assignee of the ticket.

Object Validations

Object validations take a broader approach by applying rules to objects as a whole rather than to individual fields. These validations ensure that the relationships between fields or combinations of data within an object adhere to certain constraints. For example, in a ticketing system, you might need to ensure that a ticket cannot be closed unless it has been assigned to an agent.

Validations ensure that the relationships between fields or combinations of data within an object adhere to certain constraints.

This higher level of validation is useful for enforcing business logic that involves multiple data points or for handling complex scenarios that go beyond simple field-level rules. Object validations often rely on expressions, scripts, or client extensions to make sure the data meets the organization's needs. These validations help maintain the integrity of the entire dataset and ensure that dependencies within the data are respected, preventing logical inconsistencies from being stored in the system.

Composite Key

A composite key combines multiple fields to form a unique identifier for an object entry. This is useful when a single field’s uniqueness isn’t enough. For example, fields like “Project ID” and “Task Name” may not be unique enough individually for your organization, so you could create a composite key that concatenates them. Make sure to validate fields individually before you add them to a composite key.

You can also use a composite key on the child side of a one-to-many relationship. For example, if a Ticket object has a one-to-many relationship with a Subtask object, you can define a composite key(parentTicket, title) to ensure that two subtasks within the same ticket don't share the same title, while subtasks of different tickets can. You’ll learn more about object relationships in the next module.

Expression Builder

The Expression Builder validation allows you to create custom validation rules using conditional logic, all without writing code. This is useful for enforcing complex business rules that depend on the relationship between multiple fields. For example, the value of an "End Date" field must always come after the value of a "Start Date" field. Expressions can become complex and unwieldy over time, so make sure you document them thoroughly and maintain them regularly.

Groovy

Groovy validations allows developers to define advanced custom validation logic. You should only use Groovy when out-of-the-box validation tools are insufficient for your needs. Test all validation scripts thoroughly in a development environment to prevent performance bottlenecks or security vulnerabilities.

Groovy scripting is not available on Liferay SaaS; it can only be used on Liferay Self-Hosted or Liferay PaaS, and is now disabled by default. To enable it, go to Global Menu (Global Menu Control PanelScript Management.

Client Extension

Although client extensions are out of scope for this course, client extension validations are a flexible solution for creating custom validation logic outside of the built-in Liferay platform. This approach is useful when you need to integrate with external systems or introduce complex validation rules that are too intricate for the out-of-the-box tools. To learn more, see the Mastering Liferay Client Extensions course.

Conclusion

Implementing validations at the field and object levels not only makes your data more accurate and more usable, but also gives your users a more predictable, streamlined experience with your application. Here you learned about the different types of validations available in Liferay. Next, you’ll add validations to Clarity’s distributor management app.

  • Field Configurations

  • Object Validations

  • Conclusion

Loading Knowledge

Capabilities

Product

Education

Contact Us

Connect

Powered by Liferay
© 2024 Liferay Inc. All Rights Reserved • Privacy Policy