Detailing the intricacies of the theory and use behind Field Methods.
A Field is a data object, which can be a complex data type. The support for Fields in EDO allows much of the complexities of handling these data types to be handled internally, rather than cluttering up user applications with them. Why is this useful? For many data types, we may want to show the value in different formats depending the requirements. eg; A "html" representation of an E-mail address may include a live link to the address in question. Or a "date" may be stored numerically, yet be shown as "text" in a nice human-readable format.
To reference a Field, the full syntax is:
The optional addition of a method is used to extract different formats of a Field's data, as well as provide additional special functionality. Rather than require a method to be specified every time, a default method is used, and this can be overridden using the EDO Markup <SET METHOD="defaultmethod">.
Regardless of the Field type, there are a number of basic methods supported for getting the data of a field, in a particular format. These basic methods include:
Being all about the data, there are various methods available to all Field types for representing the basic value in a "safe" format for a particular situation. For example, within most data queries (based on SQL), the data value has to be in an SQL-friendly format. Elsewhere, if the value is part of a URL, it will need to be in a HTTP-friendly format. These syntaxes usually involve "Escaping" special characters within the data.
Methods for giving different "Escaped" versions of the value include:
As well as retrieving the Field Data itself in various formats, methods can be used to access properties of the Field. As different field types can have different properties, this does vary from type to type. Properties can be used to alter many aspects of a Field; some are specific to a type of field, while some are more generic. Properties can be used for such things as:
Any property can be retrieved using the method syntax "prop_propertyname". For example, the
maximum size (maxsize) of a "string" field called "bob" can be accessed using:
In addition to all the custom properties, there are a number of default properties common to all types. Some of these are purely informational, such as the Title of a field, etc... Some of these default properties don't need the "prop_" preceeding their method calls. They include:
As well as general properties and methods, there are a number of properties and methods associated with setting the requirements for a field to be valid, and querying whether the current value is valid or not. Some field types have pre-determined validity checks (for example, an "int" field cannot have any letters or special characters - only numbers), and some field types can have custom conditions specified to determine a field's validity (for example, a "string" can have the validformat property set to a regular expression, where the string will only be considered valid if the value matches the expression).
One commonly supported property affecting field validation is the "required" property. If this is set (to anything other than blank or 0), then the field is considered to be a required field. Normally, a blank field will be considered valid; setting the field to be "required" means a validity check will come back as invalid if the field is blank.
By default, most EDO markups will not check the validity of field values. This means that it is possible for invalid data to end up in a field, which will cause problems doing queries, exports, etc...
Methods provided to test the validity of a field's current value include: