System Administrator's Guide Zelerate: AllCommerce
About Object Classes
AllCommerce has a collection of required classes. To distinguish these from user-defined classes, Zelerate reserves global event series "A" for these classes and global event series "B" through "W" for sample data sets. User-defined data should start with global event series "AA".

Name Spaces
Generally, OBJIDs unambiguously refer to a single object. There are times, however, when this may not be desirable. Consequently, name spaces have been implemented for certain kinds of objects.

A syntax has been defined to reference attributes of objects that share a class relationship. As of 0.9, these syntactical structures are not completely supported, but are provided for commentary, feedback, and to provide information on the direction the system is evolving.

Initially, there is support for only one unique name space per class. In the future, this may be expanded.

Each name space object has a uniquely-named field for the allocated names within its name space. These field names are constructed with the prefix "OS_UNIQUE_" added to the object ID of the name space (after converting "-" to "_"). E.G., for the unique name space with OBJID of "1573-A", its member names would be found in the extraprop virtual field named "OS_UNIQUE_1573_A".

Name spaces may (really, should) also have name constructors, syntax validators, and next name operators.

Zelerate suggests the following syntax to reference the attributes (i.e., bound objects) of a name space:
                {Namespace}:->{attribute name}
                {Class_Unique_Name}:{Unique_Name_Within_Class}->{attribute name}
            
Zelerate suggests the following syntax to reference the attributes (i.e., bound objects) of a member of a name space:
                {NameSpace ObjectID:Member Name}->{attribute name}
            
Core Classes
Classes are implemented with a hierarchy of core items, each of which is itself a class.
  • OS_Classes - primary class definitions
  • OS_Events - named state transitions (allowed, disallowed, or contingent on a function result)
  • OS_Fields - both core system and user-defined
  • OS_Operators - Perl-coded executable actions
  • OS_States - system states (in the mathematical sense, not the geopolitical sense)
  • OS_Tables - database tables
  • OS_Unique_Namespace - arbitrary, unique name spaces (e.g., SKUs, class names) with optional bound operators.
An example of these core system class elements is available within the file:
                .../bits/{lang}/system/os_objects.{lang}.txt
            
where "{lang}" is the selected language (e.g., "deu", "eng", "esl", "fra").

OS_Classes
Every object which is a member of this class is the model for a set of objects. There are no subclasses or inheritance, but to some extent, similar functionality can be obtained through operating on lineage information.

Specific members of a class may have more attributes than the core definition. These transparently appear in the field list when they are automatically loaded into the object definition when loaded from the database.

A class definition contains a member object list and a reference to the tables in which members reside.

OS_Events
The key to Zelerate's core systems is an event/state model where events record changes to state tables. OS_Events is the class for these events.

Events do not have states. An event happens. Subsequent events do not change the history of previous events. Events do not "have" history, they ARE history.

Events do not necessarily change state values, or may only change them indirectly. By design, events which change a state limit themselves to affecting only a single state value; events are independent.

Changes in state are made between named states (see OS_States) of an object class (see OS_Class). Each member of the event class is an object, referencing a different transition between states or values of a given class of objects. The map of allowed state transitions are the members of the class OS_Events. No other transitions are allowed.

Applications within the system include permissions and finite and known state-transition maps like those for nominal and exceptional paths for an order over its lifetime, or a purchase order or a customer.

System Events Required for Startup
The following system events are required to start the system:
  • create object (generic)
  • modify attribute
  • deprecate object
  • deprecate attribute
  • order placement
  • payment authorization
  • tracking data
  • incoming customer communication
  • outgoing communication to customer
  • pageview
OS_Fields
This is the class to which all classical object attributes belong. In the data base world, these would be called "columns" or "fields". Each field has a unique field name, a plain language name, a data type, some display formatting information, etc.

All fields, either hard-coded or handled via the "extraprop" table, are represented by members of the OS_Fields class.

The required set of fields are listed under the OS_Fields class in:
                .../bits/{language}/system/os_objects.txt
            
OS_Operators
These are similar to the member functions of a classical object-oriented language.

As implemented in AllCommerce, each operator is an anonymous Perl subroutine with at least one parameter and returning a result. All operators should be provided read access to the global public hashref, $site.

Some operations will open database connections to allow binding of validators to field definitions and the inclusion of an operator as an "attribute" of a class or object definition.

There are no required operators at the time of this writing.

OS_States
Since states are essential to the logging of events, the enumeration of the states which objects can occupy is essential to the successful definition of events. Even so, the core system ships with very few defined states, since there are very few defined objects. States cannot be implemented simply as an object class since "change object class" is a generally-allowed transaction. Instead, states are a single, unique name space.

The only required states in the core system are active and inactive.

OS_Tables
Every table in the AllCommerce system has a corresponding member in this class. Linkage is provided to a base table type (one of the physical data tables) and to the "Table Names" name space.

OS_Unique_Namespace
The name space implementation within AllCommerce is still preliminary. Check www.zelerate.org often for updates.

Core system required name spaces are:
  • Classes - unique within members of OS_Class
  • Fields - unique within members of OS_Fields
  • SKU - unique within the "things" table
  • VSKU - unique within the "variants" table
  • OBJID - globally unique within all classes and tables handling primary object or event records
Prev
System Architecture
Up Next
About the APIs
All Commerce User's Guide Table of Contents