System Administrator's Guide |
![]() |
|||
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.
.../bits/{lang}/system/os_objects.{lang}.txtwhere "{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:
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.txtOS_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:
|
||||
|
||||
All Commerce User's Guide Table of Contents |