The Phone Number Field has 6 filter types:

• Entire Field - This filter only allows Items where the entire phone number Field passes through the chosen one of the standard four item-type filters.
• Country Code - This filter only allows Items where the Country Code part of the Phone Number Field passes through the chosen one of the standard eight number-type filters.
• Area Code - This filter only allows items where the Area Code part of the Phone Number Field passes through the chosen one of the standard eight number-type filters.
• Prefix - This filter only allows Items where the Exchange part of the Phone Number Field passes through the chosen one of the standard eight number-type filters.
• Line Number - This filter only allows items where the Line Number part of the Phone Number Field passes through the chosen one of the standard eight number-type filters.
• Extension - This filter only allows items where the Extension part of the Phone Number Field passes through the chosen one of the standard eight text-type filters.

Settings:

• Display Alternate Value in View Mode - Check this box to enable an Expression Builder that you may use to configure an alternate value to display instead of the default phone number that would normally display for this Field.

Automatically pre-populate any Field so that a User does not need to type in the values themselves. This features requires use of the Expression Builder to find, manipulate, and format the data to be used for the default value.

Settings:

• Default Value in Add Mode - Open the Expression Builder to query, build, and format a default value for this Field in Add Mode.

Hints:

• Setting a Default value does NOT save the value! The User must still save the Layout.


• A User can change the Default value before saving the Layout. If you want to disallow this, be sure to enable the "View Only" feature.


• Default Values must still pass validation in order for the page to save!


• Setting a Default Value is most likely only relevant in Add Mode and therefore this setting only applies in Add Mode. In Edit Mode, there may have been a value previously set, and you likely would not want to overwrite that value with a Default Value. In View Mode, the same situation applies and in fact there is not even any saving, making a Default Value irrelevant.


• It is common to change your query's starting point to pull a default value from an earlier page or other source. In other words it is less likely that you will want to pull your default value from your inherited context.

Block Association is the tie that binds all WorkXpress Blocks to each other and enables them to work together.  There are permanent, global Block Associations and temporary, local ones. First, all Blocks are permanently associated with either an Item Type or Relationship--this defines an application's structure.  Second, Layouts and Fields can permanently nest inside of Layouts to create your interface. Third, Actions can permanently nest inside of Actions to create logic. Finally, at any point in time, a Layout, Field, or Action will temporarily be "about" a particular Item in the database, to give context.

Introduction:

• Block Association makes WorkXpress unique and powerful as an application development tool. It's the glue that connects all WorkXpress Blocks to each other.
• Permanent Block Associations define the application's structure.
• Temporary Block Associations give the interface and logic "context", which helps the application to interact with the database at a point in time.

Permanent (Global) Block Associations

Item Type or Relationship Type Association

The most basic type of all Associations, this defines your application structure. At the topmost level, an application is a group of Item Types. These Item Types may have associated Relationship Types. Collectively, all other Blocks in WorkXpress then are associated ultimately with an Item Type. Therefore, an "application" is defined as a set of Item Types and all their associated Blocks.

When searching for Blocks in the build tools, you will tend to find them by first beginning your search on a particular Item Type or Relationship Type, and viewing their associated Blocks.

This choice of Association also effects data backup and restoration.

Blocks with permanent Item Type Association only: Relationships

Blocks with permanent Item Type or Relationship Type Association: Layouts, Fields, Actions

Layout Association

To build an interface you must nest Layouts and Fields inside of other Layouts. This nesting generates Layout Association.

Blocks with permanent Layout Association: Layouts, Fields

Action Association

To build a logic model (aka business rules, scripting, etc.) you must nest Actions inside of other Actions within a procedure.

Blocks with permanent Action Assocation: Actions

Global and Local Actions

Actions may be associated with an event and block globally, or they may be associated locally.  A "Global Action" exists everywhere and every time the Action's parent Block undergoes that same event.  A "Local Action", however, only exists when the Action's parent block undergoes this specific event, in this context. In this case though, context refers to the context of the triggering Block within the interface, not the Item context.  This is a unique kind of context.

In other words, although a Field may trigger a local Action when it is saved from within one Layout, it will not trigger that same local Action when it is saved from within a different Layout.  In both cases, however, its global save Actions will be triggered from either Layout.

For example, for a certain Field, Action A is global to its "Field Save" event for all pages and Action B is local to its "Field Save" event for a specific page.  Later, that same Field is added to a new page.  When that new page is saved, Action A will fire, but Action B will not exist at all on that page (in that unique context).

Item Association and Context

An Action is always associated with the building block for whom it is a "local" or "global" action (see below).  Placing an Action in the Action Manager will result in that Action being associated with an Item Type based on where it is placed.  Actions may be associated with Layouts, Fields, Items, or Relationships.

Similarly, an Action typically requires context to function properly.  That context comes from the Block for whom this Action Manager Tool was opened and may not be the same Block for which this Action is a local or global Action.  Context and Item Association for an Action may be different.

Further, some Actions can change the context.  For example, when a list of Items is passed into an Action Manager from a "Mass Action" button in Layout Type - List, the context is each of the Items passed.  However if they pass through a "foreach" control structure, the subsequent context passed to subordinate action is that of a single one of the Items in the list, changing each time the loop is repeated.

Temporary (Local) Block Association

Temporary Item Association (Context)

At any given time, what is the page you are on "about"?  If the page is about a company, then the context of that page is the specific company it is displaying (e.g. "Acme Company", where Acme Company is an "Item" in the database of "Type" Company). Any Fields or Actions need to be about that specific item and not some other item (i.e. about "Acme company and not some other company), so those Fields or Actions need to be provided with this context. For a much more detailed examination of this concept, which is critical to successfully building applications with WorkXpress, please see our lesson about Context.

If the page is about a specific Item of Type: User...for example the "current user"...then perhaps it is about you?  When the page displays data, it needs to display that data about you.  When Actions on the page shoot off an email notifying of a change to username, it needs to shoot that email to you, not to some other User.  YOU are an Item in the database of Type User, and are also the context in this second example.

Context then is the specific Item (Not Item Type) in the database which the current Layout, Field or Action is displaying data about.

Blocks with temporary Item Association: Layouts, Fields, Actions

Who modified the Fields Value?  When did they do it?  What did they change it to? If your security policies necessitate answers to these questions, such as with Sarbanes Oxley, HIPAA, PCI and other regional privacy data acts, then this feature makes compliance easy.

Settings:

• Audit This Field - Check this box to enable auditing for this Field. WorkXpress will record each time the value for this Field changes. It will also record who changed it, and when it was changed.


• Show Audit History - Check this box to enable display of the Audit History link icon next to the Field you've chosen to audit. Click the Audit History link for a report that lists each change to the value for that Field.

Hints:

• Compliance policy is an ever-evolving thing. It is very important that review your compliance policies periodicaly to verify proper compliance.
• WorkXpress stores audit histories in a unique way, separate from the standard storage mechanisms. As such, historical audit data compiled by this feature is NOT available to other parts of your application as if it were normal WorkXpress data. This is a conscious security decision.
  
  • However, If you DO need to operate on audited data within your application, then you should simply build your own data audit mechanism. First, create an "audit" Item Type. Then, use Field Save Actions to create and populate Audit items. Your Audit item will likely include Fields such as current user, current date/time, item, field, old value and new value.  This alternate method requires more up front effort, but will yield an audit mechanism whose data are available to other parts of your application, meaning that it can be manipulated or reported on normally.