This debugger allows for advanced debugging for both development and production environments.
This did however require the implementation of an ENVIRONMENT constant. This has been put in the index file. If no constant is set it will be set by the core class and the default is PRODUCTION.
Chances are that the location for this constant will move in the future.
There is also a proper way now that fatal errors will lead to a 500 error on the screen. This is either done by Tracy or FuzeWorks, depending on if Tracy is available.
The following tests for classes have been implemented:
- Security
- Input
- Encryption Library
- Utf8
A mocking autoloader has been added (but is not yet configured correctly)
This allows the user to install new Logging templates that run in specific circumstances. By default the FuzeWorks default (as you already know it) template is installed, and a CLI one.
Closes#88
A class can now extend the Factory class and use all of its properties.
Properties like the layout system can be called like $this->layout, when extended. Just like the old days with the Bus abstract class.
Advantage of this system is that you don't require the use of extending the Factory class. Calling the factory for just one use is also possible.
Closes#93.
Now it only features one (simpler) ORM, which is the ConfigFileORM.
If a new type of config should be added, it should be done through models.
Unit tests for the basic config class have been implemented.
The Factory class is the central point for class communication in FuzeWorks. When someone needs to load, for instance, the layout class, one has to do the following:
$factory = Factory::getInstance();
$layout = $factory->layout;
The Factory class allows the user to replace dependencies on the fly. It is possible for a class to replace a dependency, like Logger, on the fly by calling the $factory->newInstance('Logger'); or the $factory->setInstance('Logger', $object); This allows for creative ways to do dependency injection, or keep classes
separated.
It is also possible to load a cloned instance of the Factory class, so that all properties are independant as well,
all to suit your very needs.
The Language Class provides functions to retrieve language files and lines of text for purposes of internationalization.
In your FuzeWorks Core folder, you will find a Language sub-directory containing a set of language files for the english idiom. The files in this directory (Core/Language/english/) define the regular messages, error messages, and other generally output terms or expressions, for the different parts of the FuzeWorks.
You can create or incorporate your own language files, as needed, in order to provide application-specific error and other messages, or to provide translations of the core messages into other languages. These translations or additional messages would go inside your Application/Language/ directory, with separate sub-directories for each idiom (for instance, ‘french’ or ‘german’).
FuzeWorks comes with a set of language files for the “english” idiom. Additional approved translations for different idioms may be found in the FuzeWorks Archives. Each archive deals with a single idiom.
When FuzeWorks loads language files, it will load the one in Core/Language/ first and will then look for an override in your Application/Language/ directory.
It is now possible to disable the modules and the events system using the config file. This will completely turn the system off.
The event system will still load the event classes but it will not send them around.
If the $keepInstance = true variable is provided for Libraries::get() or Libraries::getDriver() then a new instance will be created and returned to the user.
If the $keepInstance = false (default) is provided then the same instance will be returned as the first one.
By changing the config.core.php file you can select how registries should be cached. Remember that this is not recommended during development.
The available options are file, apc, redis, memcached, wincache and dummy. Cache TTL can also be set. Some caching drivers require you to change the config.cache.php file.
The library comes with 6 drivers: APC, file, memcached, redis, wincache and a dummy driver. Which driver you can use is dependant on your situation.
In order to build this a Driver library has been implemented. A driver can be called using (FuzeWorks\)Libraries::getDriver($libraryName); This will load the driver library and the requested library. Regular library rules apply.
Every driver comes with the same methods (found in documentation) but the 2 most important are $driver->save($objectName, $object, $time); whereby $time is an integer in minutes; and $driver->get($objectName); which will receive the cached value;
To load a cache driver you need to run something like the following:
$cache = FuzeWorks\Libraries::getDriver('cache', array('adapter' => 'apc', 'backup' => 'file'));
This will try and load the APC cache driver. If this fails it will try and load the file driver. If all fails it will load the dummy driver. The dummy driver does not actually save anything, it's just a placeholder until you fix your environment.
More information can be found in the documentation.
Helpers are small utilities that can be loaded to assist a performing certain functions. Helpers are simply global functions that get loaded when requesting them.
Helpers can be loaded using (\FuzeWorks\)Helpers::load('helperName'); Helpers can be put in the 'Core/Helpers' or the 'Application/Helpers' directory. The 'Applications/Helpers' directory is scanned first, so this one has priority over Core helpers.
It is possible to sort of 'extend' helpers. By putting a helper in the 'Application/Helpers' directory with the application prefix (found in config.main.php) you can load that helper first and then the helper in the core directory. This allows you to add or override functions without the need of copying the entire helper from the core. For example: there is a helper in the core directory named 'example_helper.php'. This one has a function named 'doSomething();' inside it. If you now create a helper in the application directory named 'MY_example_helper.php', then that one will be loaded first and can override the core class because the application helper is loaded first.
More detailed instructions will be provided in the documentation.
Libraries are small one-class utilities which can be loaded to fasten functionality for controllers and modules. It's meant to support modules and controllers but not the other way around.
Libraries can be put in the Core/Libraries directory. Libraries put here must use the FuzeWorks\Library namespace and must use the 'FW_' prefix. A library named 'Example' will be named 'FW_Example' and would be located in the file Example.php in the Core/Libraries directory.
It's also possible to extend on core libraries or completely add new libraries. Adding a new library can be done as easily as adding the file to the Application/Libraries folder. The used namespace is 'Application\Library'. Libraries that do not extend anything do not need a prefix.
Libraries that extend however require a prefix. This prefix is configurable in the config.main.php in the Application/Config directory. The default prefix is 'MY_'. If you want to extend the file should have a different name. In the 'Example' example the file should be named 'MY_Example.php' in the Applications/Libraries folder.
Libraries can be loaded using the Libraries::get('libraryName') method (FuzeWorks\Libraries::get()).
A module advertises it has certain data, identified by a key. The moment a module gets loaded that listens for that key, it will get send this data.
Using this technique it is possible to load certain predefined data into modules, without loading the actual module. This data is prone to future caching as well.
- Modules can now be loaded using routes by adding a routes[] array to the moduleInfo.php. When it matches, the module gets loaded, and a route() function in the main class gets called. (Fixes#79)
- Composer can now load from a different file
- License headers have been added to all core files (Fixes#66)
- Table model has been renamed to sqltable. Interpret model has been removed
- layoutLoadViewEvent added
- Controllers now extend the \FuzeWorks\ControllerAbstract class
- Controllers are now in the \Application\Controller namespace
- Models are now in the \Application\Model namespace
- Events are now in the \FuzeWorks\Event namespace
- Moved some classes in a different namespace for a better overview
- Events can now properly load function listeners (fixes#81)
- Documentation added to more classes. (Partially fixes#58)
- Added replace() command to DatabaseUtils Abstract Model
- Added more unit tests for router, query and events
