The Address Field has eight parts:

• Street
• Street 2
• Street 3
• City
• State
• Postal Code
• Country
• Address Type

Appearance in a Field Grid

Customize the space your Field occupies using different sets of configuration options depending on which kind of Layout the Field appears in.

Customize the space your Field occupies in a Field Grid Layout.  A Field Grid Layout is like a table with columns and rows. A Field can occupy more than one column and/or more than one row. This gives you the flexibility to arrange Fields in a grid as needed.

Settings:

• Column Span - Set the number of columns across which you'd like the Field to span in your Field Grid. By default, a Field Grid Layout has two columns, and a Field spans one of them, thereby taking up 1/2 the width of the page.


• Row Span - Set the number of rows across which you'd like the Field to span in your Field Grid. By default, Fields are set to span a single row.

Hints:

• "Columns" go across, and "Rows" go down.


• By default, Fields always occupy 1 column and 1 row.  A Field Grid Layout by default is set to 2 columns wide, and will create as many rows as needed for the number of Fields it contains.


• You will commonly set "long text" fields to occupy 2 columns in a 2 column Field Grid Layout, so that it spans the full width of the page.


• Spans "move" with your Field, so if you drag and drop it to a different part of the Field Grid, it will retain the row and column spans entered here and apply them in the new location.


• In a typical Field Grid Layout with 2 columns, you can set a Row Span of >1 and a Column Span of 1 to get the effect of putting multiple Fields next to a single Field.  For example, set the Row Span of an Address Field to 3, so that you can put 3 entire Fields next to it, creating a more efficient presentation.

Appearance in a List

Customize the space your Field Label occupies as a column header in a List Layout. Also adjust the alignment of the data presented in each row. Adjust column size, text justfication and even sorting behavior.

Settings:

• Column Width - Enter the width of the column, in pixels, in which this Field appears in your List Layout.


• Align Header Text - Choose "Left", "Center", or "Right" from the selection box to align the Field header in your List Layout.


• Align Data (Horizontal) -Choose "Left", "Center", or "Right" from the selection box to align the data displayed under the Field header in your List Layout.


• Align Data (Vertical)* - (feature in progress)


• Default Sort - Check this box to set this Field to be the default sort Field for this List Layout. When checked, a select box will appear to the right of this setting that will allow you to choose "Ascending" or "Descending" for the sort order.

Hints:

• When thinking about pixel sizes, as a very rough rule of thumb to help you enter your first value, think of a letter as occupying 10 pixels.


• Remember, not all users have the same size screen. The WorkXpress workspace by default is set at 1024 pixels wide, but the space available to the builder is slightly less.


• By default, column widths are calculated automaticaly by your browser. When you begin fixing the widths of columns, the browser will assign that width, and then automatically calculate the remaining columns based on the remaining width available. By playing with columns widths and fixing the things that are important to you, you will arrive at a powerful combination of widths that are fixed and widths that scale based on the content of their Fields.


• Sort by a column if necessary, but generally you don't want to do it "just because".  Sorting takes up processor power, and therefore consumes some performance.


• Sometimes the values in the rows of a column occupy little space, as is the case with an icon or a single letter or number.  In these cases, it may be unsightly to have a long Field Label used as the column header; the columns will be very wide, but will contain narrow data.  In this cases, simply use the "Field Label" feature and setup an "Alternate Field Label" to be used just for this column label.

 Appearance in a Tree

Customize the space your Field occupies in a Tree Layout.  Each level of the Tree is like a list column header, and gives control over column width and sorting.

Settings:

• Column Width - Enter the width of the column, in pixels, in which this Field appears in your Tree Layout.


• Default Sort - Check this box to set this Field to be the default sort Field for this Tree Layout. When checked, a select box will appear to the right of this setting that will allow you to choose "Ascending" or "Descending" for the sort order.

Hints:

• Each level of your Tree Layout is like an individual List Layout, so treat it as such!

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.