********************************************************** config/factory.txt $Id$ @author gERD Schaufelberger @copyright 2004/2005 Wombat Web Bench @link http://wombat.exit0.net @package wombatSite @subpackage manual ********************************************************** FACTORY ======= As described in genesis, world was created within six days and after that god needed to rest a day. In modern times things are created by engenieers, build at assembly lines and robots or computers don't rest on sundays. Even though the wbFactory creates the world (of wombat) within milliseconds. :-) According to object oriented design patterns a factory class is responsible for instanciating objects. The wbFactory is sort of a abstract factory which provides some other related funktionality. It's responsibility is to instanciate objects, keep track of them. From the application's view the factory acts like a real world factory: it supplies the "public" with goods, ready to use. In other words, wbFactory is also responsible to configure all created objects. All in all, the factory is a great utility to make application developers life easier. As a developer you don't have to bother about includeing files, instanciating classes, passing references and configureing them - just "buy" the requested object from the factory. The "price" you pay is the overhead that the factory-class produces (Well, we try to keep the processor busy). CREATE THE WORLD ================ In order to fullfill its task wbFactory needs to know a bunch of things. E.g. to include classes it must know where to find the matching PHP-files. Actually the factory "knows" heaps more - but luckily, the factory is capable to figure it out by itself or the fallback values will do the job. See chapter "setup the hen" in config/global.txt. Typically, the configure-function is called without a parameter, still it supports two parameter: wbFactory::configure( 'conf/myconfigFile.php', true|false ) The first parmeter is the name of "configuration file that will be executed. The second one, tells the factory, whether the php and xml-configuration file will be loaded at all. In the rare case, no configuration is loaded, the factory is still capable to include classes (and more) but not to fullfill all tasks. (The application using a half-configured wbFactory is wombatmake - the install. Because the system is not installed properly, it processing xml-files etc will fail anyway - or lead to wrong results. Therefore it starts with an uncofigured factory and loads the configuration on the fly.) In any case, after calling configure() the debugger and error-handling are set up and running - we are out of the woods. Also wbFactory has got another static function (rarely used): wbFactory::loadSiteConfig() It will load the global configuration stored in an XML file - conf/config.xml by default. Again: this function should only be used if configure() is called, without processing the configuration. Otherwise, this function will overwrite the current configuration - which may cause heaps of trouble. FACTORY PARAMETER ================= As mentioned above, the factory requires a bunch of information to run - factory parameter. The factory also provides a static interface to get and set those parameters: $value = wbFactory::getParam( 'name' ); wbFactory::setParam( 'name', $value ); While getParam() is used by various apllications to recieve some configuration values, setParam() should be only used during initialization (or by the factory system itself). To setup your site properly, you may want to adjust some parameters. See config/global.txt to see where to adjust those factory parameters. Even if not all - or just a few - parameters are mentioned to be adjusted or changed during startup, the following list describes all available parameters of wbFactory: Desciption of factory parameters -------------------------------- 'site' subclass of the site runner - default is "". Examples: "Cms" 'systemDir' the installation folder, this is where all the classes etc are Will be found automatically! DO NOT CHANGE! 'baseDir' Location of client's site. Allows multiple client installations in a single womabt-installation. By default baseDir is the same as systemDir. 'debug' Either 0 or 1 - switch debugmode on or off. Debugmode is usefull during development, switch off on life-system! 'debugMode' Default: "Html" - select suitable debugger. 'useCache' Either 0 or 1 - switch caching feature on or off. Default: 1 'htdocDir' Location of the web-root - relative to baseDir. Usually, the default, "htdoc" should be alright. 'configDir' Location of your configuration files. Path relative to baseDir. The default value "conf" should be good. This should only be adjusted, if you want to run two separate wombat-sites within the same baseDir (example to use a different pages, ...). 'configFile' Name of the main configuration file, default value: "config.xml" This may be changed if you need to change the layout or other global configurations for a special part of your site. Note: per-page settings can be changed in page wide scope! 'adminDir' Where to find all site-admin stuff Will be found automatically! DO NOT CHANGE! 'varDir' The default value "var" should suit most cases. 'includePath' With this path, wbFactory is able to load php-classes Will be found automatically! DO NOT CHANGE! 'localClasses' This array lists class-prefixes and include-folders of php-classes that can be included from includePath. All other classes e.g. PEAR-classes don't come with a the Wombat intallation and cannot be included locally. Still, if your php.ini is set up proberly, using server-wide classe (e.g. PEAR:DB) is not a drama. The default values should be alright and match the current version of Womabt Web Bench. In other words: DO NOT CHANGE! 'singletons' This is just a container where all created singletons will be stored. Therefore it is not a real parameter and this means: DO NOT CHANGE - NEVER EVER! 'config' This will hold the global config read from configFile in configDir. This parameter is not meant to be changed, but you can easily access the config with: wbFactory::getParam( 'config' ); Again: DO NOT CHANGE! 'lang' This is to keep the current locale settings for easy access with wbFactory::getParam( 'lang' ); This parameter is set during the localisation process, hence: DO NOT CHANGE! 'timestampGenesis' Well, this let's the factory know when it was "born". :-) Even if it is not the exact "start of life", it will be used to meassure the complete processing time. Therefore it gives you an idea about performance etc... DO NOT CHANGE! BTW, the wbDebugger - which is allways running - utilizes time meassurement. So, don't muck around with microtime(), use the stopwatch-features of wbDebugger! In other words: DO NOT USE wbFactory::getParam( 'timestampGenesis' );