The packages and applications are named all small case without underscores (example "resourcelock"). The name must be a valid namespace name.
The classes may follow camelCase or use underscores. In fact these two are combined in the name of the configuration files (like "activeEnvironment_config").
When a framework class is supposed to be extended by user classes its non-private members are prefixed with underscore ('') in order to avoid any name collisions. This policy is followed for the "framework\base\classes\base" and "framework\mvc\classes\controller" because they are supposed to be extended with a lot of code and the provided methods are not related to the functionality they will provide. In reverse altough the class "framework\orm\classes\activeRecord" is inherited by many classes (basically near all models) its members are not prefixed as they are strictly related to the functionality the the child class will provide. In short if you are developing only on top of guzaba dont create any methods/properties starting with '' as this is reserved for Guzaba names. Similarly do not use any names starting wit htwo underscores ('__') as they are reserved for PHP "magic" functionality.
Guzaba framework organizes all files in packages and the packages are organized in applications. The files of the framework are under the ./framework/ directory (all paths given from now on are relative to the directory where index.php file resides) and altough it is not application by it self inside the whole project is reffered to as it is. Inside the ./framework/ directory reside all the packages of the framework. A package can consist of up to four file types (by purpose): classes (the main and configuration classes of the package), exceptions (all classes that inherit the \Exception), interfaces (for interfaces only, the abstract classes should go in "classes") and a directory for soem type of resources that a specific package may have. The resource folder may have optionally subfolders - there is no fixed hierarchy for it. The naming convention for the package names is all lowercase (no camelCase) and no underscores. Even when the package name is comprised of two words they are written as one word (like "resourcelock"). Inside the package main directory are (none is absolutely required): classes, interfaces, exceptions, resource.
The framework uses namespaces and they correspond to the file structure. Namely the file "./framework/authorization/classes/monitor.php" has namespace "org\guzaba\framework\authorization\classes" and the class name is "monitor" (the classes will be reffered using their full namespace or optionally omitting the leading "org\guzaba", this just giving "framework\authorization\classes\monitor"). Each class resides in its own file with the exactly the same name (don't forget - UNIX is case sensitive).
All classes in Guzaba framework (and the CMS) inherit one base class "framework\base\classes\base" with very few exceptions (the most notable one is the "framework\kernel\classes\kernel" class but more on this in section 3). Each class can have an optional XML configuration file, based on which a configuration class is generated (more on this topic in section 3.2). This way a typical inheritance structure may look like:
This tree like class structure (with the root nore being the base class; more precisely base_config) and the configuration files for each class permit to have settings placed in different locations in the vertical structure thus giving them different visibility. For example when a variable must be accessible by all classes it can be put in the base_config class. If a variable must be accessible only by a group of classes it can be put somewhere in the middle of the vertical structure. Consider the following example (classes are given without their namespaces):
In this case if all classes that are object-relational mappings need to have a common setting it can be put in activeRecord_config. And of course for class specific configuration its own configuration file (like "subject_config"). This way the need of a centralized "Registry" is avoided and the capsulation provided by the classes and the proper tree structure permit to reduce the accessible variables for each class.
The naming convention for classes is camelCase. The configuration file should be named className_config.xml.php.
Base package and base class
In Guzaba framework overloading is used extensively. The base class ((fully qualified name "org\guzaba\framework\base\classes\base") provides the overloading functionality altough some of the child classes may override it. Besides overloading the base class provides auxiliary methods - many dynamic and few static. For understanding the basics of the system is not required to fully understand the overloading nor to know all the auxiliary methods so the reader may skip the next two sections and proceed to 2.5 Singleton.
Overloading in base
Auxiliary methods provided by base
Exceptions in the base package
baseExcetpion - an abstract class parent of all other exceptions. It is very important every exception defined and thrown in Guzaba to inherit this class as it performs important tasks on security and transactions (it rolls back any current transactions)
configurationException - should be throw when a class detects a wrong configuration set in its config.xml file
logicException - it is thrown by framework\base\classes\base::_assert() method (it can be thrown outside this method but this will be disabled in future by calltrace checking)
notImplementedException - for not implemented functionality
parseTimeException - the name is actually misleading (to be changed in future) as it is thrown during the execution but reflects a call that under Guzaba policy should never be executed the way it was (hence it was called parse because it does not depends of the runtime events)
runTimeException - for all other exceptions...
Guzaba does not use the exceptions provided in the SPL, because then it wont be possible to have one basic class for all exceptions.
The singleton class ("framework\patterns\classes\singleton") provides the Singleton pattern. It provides one static method get_instance() to the child classes (the class it self is abstract). Its constructor permits only one invocation with the "new" operator (altough get_instance() is always preferred).
There is one basic with static only methods class "framework\filesystem\classes\paths" for handling filesystem paths as arrays. This class does not inherit base, because it is used very early in the system initialization when even the ernel (which provides autoloading and configuration classes generation) is not created.