profile

There are different types of profiles in Interchange:

search profiles
form profiles
user profiles (see Profile)
UserDB profiles (see UserDB)

Form Profiles

Interchange form profiles are used to validate form inputs and eventually trigger additional actions. The validation usually consists in requiring that some of the fields are non-empty or match a specific regular expression pattern.

Profiles are not specific to order checkout or any specific step; they are an integral part of all form processing in Interchange. You will also see actions such as Interchange account creation, login, logout or password change being at least partly handled using profiles.

Profiles can be defined in external files (and activated using OrderProfile) or in scratch variables. External files are, by convention, kept in CATROOT/etc/ and begin with profiles.. Multiple profiles can be defined in each file.

A very simple hello world-like profile example follows:

  test_profile

fname=required
lname=required

The above profile requires customers' first and last names to be entered.

	Note
	The and markers must start at the beginning of line, not even whitespace is allowed. This is very important because the profile would otherwise be silently ignored.

If users leave some of the required fields empty (or there's some other reason why you'd want them to correct their input), you'll probably want to show them the form page again and display some kind of an error message. To override the default messages, simply specify your own strings after the format check specification. Here's an example:

  test_profile

fname=required First name is required!
lname=required Last name is required!

Format-check Specification

From the examples above, you can see that the format check specifications are specified as FORM_VARIABLE_NAME=CHECK_TYPE. Form variable names are obvious; in our example they were fname and lname. Check types, however, can take on one of the following values:

required - form field must end up with non-empty content. If no direct CGI variable exists, variable is searched in the the values space (form fields submitted at some past time during the session) and UserDB
mandatory - form field must contain a non-blank value, and it must exist directly on the form being checked. In other words, it must be a CGI variable and not a value variable coming from some previous form input or UserDB
phone - form field must look like a phone number (by a very loose specification), allowing numbers from all countries
phone_us - form field must have US phone number formatting with area code included
state - form field must contain an US state, including DC and Puerto Rico
province - form field must contain a canadian province or pre-1997 territory
state_province - form field must contain an US state or canadian province
zip - form field must contain an US postal code formatting, with optional ZIP+4. This is also called by the alias us_postcode
ca_postcode - form field must contain a canadian postal code formatting (check for a valid first letter is performed)
postcode - form field must contain a valid US or Canada postal code formatting
true - form field content must begin with y, 1 or t (case-insensitive)
false - form field content must begin with n, 0 or f (case-insensitive)
always_pass - form field always passes. This can be used to update the field regardless of the value
email - form field content must pass rudimentary e-mail address check; it must contain "AT" (@), a name, and a minimal domain
regex REGEX_PATTERNs - form field content must match regular expression patterns. Multiple patterns can be specified, separated by whitespace
length RANGE - form field content must satisfy the allowed length range
match CGI_VARNAME - form field content must be equal to the content of another field, CGI_VARNAME
unique DATABASE - form field content must not exist in a given DATABASE
filter FILTER - form field content should be equal to the original value after being ran through the specified FILTER

Chained Checks

Checks can be combined with the &and and &or profile operators. The following example uses the regex and length checks to ensure that the input is suitable for system usernames and is within certain length bounds.

username=regex ^[a-z][-a-z0-9]*$ "Invalid characters in username."
&and
username=length 6-32 Size limits exceeded (6-32 characters)


price		reconfigure