What is WorkXpress?

Well, you can check out the marketing version of what WorkXpress is here : http://www.workxpress.com

I can give you the short story here :

The Engine
WorkXpress is an engine for building applications that are served over the web. It is designed with a high level of usability in mind, so much so that the goal is to allow non-programmers, people who are essentially "really good with Excel", to create sophisticated, totally customized (and customizable) web based applications to run their department, their division, or ultimately their whole company.

The Technology
The technology is based in the open source world of products utilizing PHP, MySQL, Apache on Gentoo Linux based servers. We use other open source packages such as many PEAR packages and JQuery for javascript.

How it works
The website has a bit about the building blocks on it but I'd like to talk about them from a more.. traditional-programming perspective.

Items
In WorkXpress, we track things. These things can be grouped into types. In any CRM Tool people track Contacts and Companies. These things are types of items, or Item Types. Each individual Contact or Company is AN item.

You can think of Item Types like Tables in a traditional database model. When you're designing a CRM Tool, you decide you will definitely need a 'Contacts' Table, and this table will have columns like "First Name", "Last Name", "Phone Number", etc.

In WorkXpress, the Table is an Item Type, the Columns are 'Fields', and each Row in the Table, is an Item.

Item Types's go a few steps further than tables, and start to be more like OO Classes when you add Rules. If Fields are like Member Variables in your class, then Rules are like Methods. You can (through a web-based, point and click interface) build simple, or complex methods which are fired when certain events happen. For instance, there is a set of Rules that fire when an Item of that type is created (like the constructor of a class), an item of that type is recycled (destructor). The difference is that the instances of these classes are preserved, saved in the database, so they are available to other users, and they are available the next time you login, etc. Much like rows in a table.

Fields
We've already covered Fields a bit, they are simply data stored on an item. When you create a field, you setup it's parameters like a label, width, max characters, etc. These options vary greatly based on the type of field you create. Currently, WorkXpress supports over 40 Field Types, from the familiar and common Text Box, Text Area (Long Text), Check Box, and Select Box to the advanced field types like Date/Time Pickers, Rich Formatted Text (Like a forum post body, blog entry, etc. where you have formatting controls), Item Selectors, File Uploads and Buttons.

Some field types map directly to INPUT elements, and some are a collection of Javascript and INPUT elements to create a very pleasant user experience using these fields. The goal here is to make each field type as naturally easy to use, and familiar as a select box.

Layouts

Stepping out of backend world for a second, every application needs an interface. Some of the elements of the interface are provided by the fields that are created/placed on a page. The remaining interface elements are provided by a block we call Layouts.

First, each page in WorkXpress is just that.. a Page Layout. This Layout has one important job : receive the information about what item we're going to show data for, and draw it's child layouts with that information.

Inside each Page Layout is a series of other layouts, of varying types. When a new Item Type is created, an Add Page and a Home Page (or View Page) are both created, a single Field Layout is created, and placed on both the Add and Home Pages. Then, the first field is created and placed on this Field Layout, giving the implementer a very basic framework to start with.

So, one major type of Layout is a Field Layout. This layout.. shows fields and allows those fields to be edited.

Another major type of Layout is a List Layout, or Related Item List. This layout shows a list of items that are attached to the item the page is about, via relationships. The implementer sets up what columns (Fields) are shown about each related item, and the Layout allows new relationships to be added, and existing relationships to be destroyed.

Relationships
Ok, so I have Contacts (Drew, John and Sally), and I have Companies (Express Dynamics, Best Buy) and I want to somehow store the fact that Drew is an Employee of Express Dynamics and John and Sally are employees of Best Buy. How do I do that? We have created relationships to track exactly this kind of situation.

First, you create the Relationship Type. Much like an Item Type, a Relationship Type describes the kinds of relationships we're going to make. In this case, we want to Relate Contacts to Companies, and we want a related Comapny to be called an "Employer" and a related Contact to be called an "Employee". These 4 pieces of info (Item Types on both sides, names on both sides) is all it takes to setup a relationship.

Second, we create some way to create these relationships. For this we have 2 constructs.

The Item Picker
The Item Picker is a type of field, that allows either 1 or many other items to be selected on an item. So, if you wanted a field on your Contact that allows you to select this Contact's Employer from the list of all Companies, you would create an Item picker on Contact, that selects Companies. On the item picker, you can choose a relationship for it to automatically create/maintain as the fields value is changed. It's important that we create the relationship as well as set the pickers value if we want to access this contacts employer later, through Actions.

An Item Picker with a value filled in (Employer Field on a Contact) will show the selected item's Name field, with it's Icon as a link to the selected item's Homepage.

The List (or Related Item List)
As described above, the List is a Type of Layout. It can be configured to use one or many relationships to show related items, and the implementer gets to pick what columns to show about the related item. So, in a List Layout one could show not only this Contact's Employer, but also its address, office line, yearly revanue, etc. Any other fields about Company the Implementer see's fit to show.

This is highly applicable on the other side, from the Company. One could show the first and last names, Email Address, Phone Number, Birthdate, etc. of each Employee attached to the Company (which there may be several).

Actions
Actions are programmatic functionality setup to be executed at various specific times while the application is in use. Actions can be added to Fields, Relationship Types or Item Types. Fields can have actions before and after saving, and before and after clearing that field. Relationship Types can have actions before and after creating a relationship of that type, before and after recycling a relationship of that type, and before and after deleting a relationship of that type. Items has a longer list, some of the highlights include before and after adding an item, updating and item, and recycling an item. These "times" when actions are executed are called "Events".

Each action can be configured to run on one or many events. So if you have something that you want to happen when a user adds a Contact, and anytime that Contact is updated, you can write one action and put it on both events.

Each action has 3 parts : evaluation, operation on pass, operation on fail.

Evaluations occur before any action takes place, the if in an if... then... else... type format, the evaluations job is to make sure that this action should run now...

Operation on pass and fail are the same, they are just the then... and else... parts in an if... then.. else... format. There are many Operation types that do many types of different things. They all have point and click interfaces to setup.

One quick example of an action is the age old "We want to store and sort contacts in a "Last Name, First Name" format.

No problem. Add an action on after add and after update with no evaluation. Make the Pass Operation a "Build String" operation, and begin building your value. You are presented with a map of information, starting on Contact (since you're writing a Contact Action), which shows all the fields on Contact. Click Last Name, "Finish", and you've added the first piece of the string. Then add just a Comma, and lastly choose First name from the map.

Then, you select a place to store this new string, which will also show a map, starting on Contact. Select "Contact Name", which is the field responsible for showing the Contact in pickers, and at the top of the homepage, etc.

You can also use actions to grab values from items through relationships. Let's say you have an "Employer Address" field on Contact. This field is supposed to show this Contacts, Employers, Address field. No Problem! Add an action, and use the map to navigate from Contact, across to Company through Employee -> Employer, and select the Address Field. Choose the local (Contact) "Employers Address" field, and save.

More on Items, Fields, Layouts, Actions and Relationships soon! Stay tuned!