Introduction

Class TagSystem

Class TagSystem: This class is deprecated and should not be used anymore (deprecated since new variable system was implemented, which is independent from administration dynamic attributes).

This class has not been removed, some time should be spent verifying that all usages of it have been removed and then, the class itself should be removed.

Class TagReferenceSystem

Class TagReferenceSystem: This class uses the new variable definition system to allow any variable object (variable definition, relation or attribute) to be refered via a tag or tag chain (separated by dots or .). This system was created so as to remove the multiple ways the variable objects were refered with throughout all the systems that needed it.

When a variable object is stored in the backend, a slug is generated for it (VAR##### for variable object, REL##### for relations and ATTR##### for attributes).

The variables that are not related to any other variable are considered root variables. The tag is constructed in such a way so as to locate the target object in relation to a root variable (for example VAR00001.REL00002.REL00004.ATTR00018 where VAR00001 is the root variable and the various relations navigate to the attribute).

This system is being used in the forms to point a field to a variable's attribute, in WeFlow scripting language as a reference to various objects (variables and attributes) and can also be used in a word template as a tag for the word to pdf system (invocable from WeFlow) using the format example ${VAR00001.REL00002.REL00004.ATTR00018}.

As an historical note, the format VAR#####.VAR#####.VAR#####.ATTR##### can also be used but there is a chance for problems because it is possible to use the same variable object in multiple relations in the same variable object, so this format will match the first relation with the variable instead of the relation itself (less precise, this is a holdover from an older system). Whenever possible, the VAR(...).REL(...).ATTR(...) should be used.

The tag system can also reference fixed case information by using the tag starter CASE plus the fixed attribute's tag (for example CASE.CODE or CASE.CREATED_BY).

This system uses rejex matchers (declared at the top of the class) to detect whether a tag has been used in a text, this allows the tag to be inserted as part of a title / message (message task) or as part of a fixed freeform text (frontend / user task) to replace that tag with the text version of the value.

This system can be configured for value or text_value, this is already configured for all cases but it is usefull to know in case a new context / system that requires tags is implemented, this is important for the "model type attributes" like of type User. If it is value, the user attribute returns the user id, if text_value is set, then the tag is replaced with the user's name.

WeFlow and form fields uses the value setting while other systems use the text_value.