With a single file the MF provides you highly scalable object oriented framework in php to think, write and deploy web applications which run faster. This is a no nonsense framework which has just what is barely needed. Any frills has to be added. The addons and plugins provide a method for reusable extensions making the system rich. The MF is currently released as single file. Plugins and addons from the community is provided for reuse and extend.
It does not matter if you are a beginner, or expert. MF will help you push applications to production in very short time. Though it is all object oriented, you can still run applications which use only addons. Means they can be procedural. Though the MVC concept is still there, this framework reduces code complexity and provides application performance and product delivery.
If this framework is useful to you, and you are extending this using either plugins or addons, we suggest that you submit them to the respective repository such that others will also benefit from the same. Even if you dont have a submission, and just only a comment in the wish list, we welcome that too.
No system is complete without configuration. The web server will need some configuration for initial routing, where as we have our routing system. So mostly all web servers would be contented with a error handler being re-routed to our controller file. Any portal, or web application can exist and run with just an index file, and its views in the specified path. Paths and directory structure are loose, though need be specified. If a log file is needed, the logfile name should be provided, and the file should be writable, or the path should be, by the web server process.
Apache: using rewrite rules
Lighttpd: using server.error-handler-404
nginx: using rewrite rules
Best location for the MF.php is a singular shared location, such that it can be shared across all applications on the server, but there is no hard rules. The controller should have the include directive with full path to MF.php. If you are going for the shared location, then move the MF.php to the shared location instead of copying.
MF::set( String $var, Mixed $val ) and MF::get( String $var )
These are used for setting a variable into the global scope (as a part of a static array map), and such that it can be fetched later. Since most of the functions are statically invoked, the variables may be having different scopes, and may not be available. To over come this, the set and get functions are used. These are used to preset some paths for the system as well as to switch on the file based logging.
The minimum required settings are urimask, addons, extend, views whereas some optional settings, are logfile, dsn, global etc. addons, extend and views are the critical ones, and should be directories, and have a trailing slash. logfile should be specified only if you need a log into the file whenever MF::debug() is called. global is expected as an array, other wise it wont do any purpose. This var will be taken and extracted such that the key => value will be available as $var = value in the scope of MF::display.
MF::addon( String $addon [, Mixed $params , [ Mixed $params ] ] )
Addons are singlular files containing just functions, and the function names should be the base name of the value in addon, the '.php' will be assumed and attached when including the file. Example has one addon 'benchmark' configured for the purpose of explaining the addon more.
MF::object( String $item, [ bool $newIfNotExist Default true ] )
Keeps, checks and makes sure that any object instance is created just once. It may be called as an object singleton store.
MF::MFR( String $route, String $class, String $handler [, int $cacheable ] )
The routing handler, such that you could specify the valid <method> <resource path> to send the system through the routes. The path value set in 'extend' is prefixed to the $class, it is instantiated through the singleton registry and the $handler method of the instance is invoked. The <resource path> is applied to the $_SERVER['REQUEST_URI'] assuming that the <resource path> is regular expression, means you can use regular expressions, and the resulting match array is passed as a parameter for the $class->handler method. For the parameter $cacheable to work, the plugin PageCache should be existing and instantiated before the routing starts. PageCache need only be instantiated with MF::object('path/to/PageCache'), and PageCache will get attached itself to 'before-handler' and 'after-handler' event hooks.
MF::display( String $view [, Mixed $vars ] )
Of course without a view renderer, what is the point in having a framework. Though for the actual rendering, power of PHP is utilized instead of wrapping it again to make the template complex. This basically means that the looping, variable outputting etc is done in the template file, and the file should be having a '.php' extension. Here the possibility of spaghetti code exists, means a '<div>' starting in one file may be closed in another file. But we (rather our designers and html integrators) were in fact familiar with that kind of template structure as we all are working with wordpress for a long period.
MF::run( [ String $page ] )
This was dropped in after a struggle that our testers found that for any url, the system is just accepting it.. and for any juggled up url, the system does not give the expected 404 status. And when going through some other solutions parallel to mine, there was this kind of a call. Actually this is used for checking and sending a 404 header. Since we used this for a well documented API, we were not worried about the blank 404 page. On an after thought added the page parameter, which could point to a well written 404 page, which could entice the users into visiting other parts of the system. For making this more efficient, you could wrap an addon which will output a 404 header and a blank page for the bots whereas the nice formatted apology page for a genuine visitor. Simple Bot Detection with PHP could be used as a base for the same.
MF::debug( Mixed $var [, Mixed $var ] )
Logging as main part of development and the debug method compliments that. By default, the method will output the passed in parameters to the standard output that is the web page that is being rendered. But in case the logging has to be done in production, the debug messages would give a fright to the client. Hence setting a logfile var using MF::set('logfile','/path/to/logfile'), and the value can even be customized with date and or time, to control the file size.
The framework is pluggable if some standards are followed. And plug-ins are written with those standards in mind. Checking out the plugins published herewith or included in the sample application, one can know how plugins can be written. Pear classes can be implemented without much complications. Addons are meant to be single function snippets, which could be used through out and where ever needed. Anything that requires more than a function should be moved into a plugin class. Pluggins are nothing but instantiatable classes, with public methods and private methods.
Methods MF::addaction and MF::fireevent provide a facility to create hooks and attach methods to them transparently. Making plugin authoring a breeze. This is the major update from release 0.21 to 0.22. About 7 event hooks are already available in the MF system. Others can be added by plugins, or themes.