Introduction

Previous processing setup

Currently, there are several approaches to rendering user fields:

• using components system.field.edit and system.field.view with templates for user fields of various types. These components allows to render an element either in view mode, or in edit mode;
• using CUserType old core classes, for example, CUserTypeString or CUserTypeInt, which contain UF-fields rendering methods for various conditions;
• individual element rendering in specific components. For example, this method is used for workflows and the new filter in the admin section, as well as for CRM entities in the mobile app.

These approaches have some disadvantages:

1. support complexity (now js, html and php "mixed" in methods of class CUserType);
2. support complexity for various device platforms (desktop, tablet, mobile version and etc.), when field must be displayed for each device by various methods;
3. complexity of field display methods (for example, field rendering by a special unique method needed for some specific component);
4. extension complexity (when creating new field template component, it must be implemented for all existing field types, even if a unique rendering is needed only for several field types, and other fields are well suited with standard templates);
5. labour hours needed for creating new field type.

Upgraded approach

Updated approach handles user field class and its corresponding component that contains all necessary templates. For example, now there are the following combinations available:

• main/lib/userfield/types/StringType and main/install/components/bitrix/main.field.string
• iblock/lib/userfield/types/ElementType and iblock/install/components/bitrix/iblock.field.element

To ensure backward compatibility, old UserType classes have been preserved as stubs.

Calling components system.field.edit and system.field.view also lead to triggered calling field rendering via new API.

Note: updated approach is available from Main module version 20.0.800.