![]() |
||
![]() |
1.0.4 Documentation | ![]() |
![]() |
![]() |
6. Customizing the Installation6.1 Look and Feel6.1.1 Clean HTML6.1.2 Template Creation and Customization6.1.3 JumpTo Navigation6.1.4 Reasonable Graphics6.1.5 Interaction of Graphics and Templates6.2 Custom Object ClassesAllCommerce 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". 6.2.1 Unique Object Identifiers6.2.2 Name SpacesGenerally, 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} 6.2.3 Core ClassesClasses are implemented with a hierarchy of core items, each of which is itself a class.
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"). 6.2.4 OS_ClassesEvery 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. Important: 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. 6.2.5 OS_EventsAs described in section [Sarah, section #], 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. The following system events are required to start the system:
6.2.6 OS_FieldsThis 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 6.2.7 OS_OperatorsThese 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. 6.2.8 OS_StatesSince 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:
6.2.9 OS_TablesEvery 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. 6.2.10 OS_Unique_NamespaceThe name space implementation within AllCommerce is still preliminary. Stay tuned for details. Core system required name spaces are:
6.3 Customizing the Code6.3.1 Style Guides6.3.2 custom.pm6.3.3 Anonymous Routines6.3.4 Changes to Core Scripts |