FD-Core v.1.2.4 by Fanatical Dev
OpenID/Facebook connect based micro PHP framework - view on Github
Last update: 30/09/11Introduction start here top ↑
Fanatical Dev Core (FD-Core) is a micro-PHP framework, with built in OpenID and Facebook connect controls. It has the following features:
- User login system (via OpenID/FB connect)
- Add openid/fb account to existing user
- A full user permission/rank system
- Self-protecting database class
- Very basic templating system
- Session/token management for forms
- Debug all pages (log, mysql queries and time taken)
- Notification system (requires js front-end code or similar)
- Suggested (not forced) app structure, with helper functions
- Very little overhead (hopefully)
- Self-location aware
App Class suggested app structure and helper code top ↑
Suggested App Structure
- core/[FD core]
- app/
- lib/
- load/
- process/
- templates/
- config.php
- index.php
This setup means every request is one either:
- index.php?load=<load file>
- index.php?process=<process file>
Using .htaccess these can easily be changed to any desired directory structure
Loads, Processes & Templates
Most app's can be broken down into three types of file, based upon two types of requests (loads & processes).
- Loads are used to 'load' data, they normally start the template class, get data for the template and then load the template.
- Processes are generally POST requests (but can be GET) and 'do something' to a database/etc, and redirect at the end (normally to a load).
- Templates are mostly html files, with template data displayed where needed.
As you load the core classes, any variable name can be used (as with the config array), I perfer to use $mod_<class name>.
config.php simply contains an array of any name with all the app configuration (MySQL data, etc).
Example Index.php
Individual functions are described in their own sections, but it should make sense to anyone with PHP know-how.
//map loads/processes
$map_loads = array(
'load_name' => 'load_file'
);
$map_processes = array(
'process_name' => 'process_file',
);
//start THE CORE!
require_once( 'core/core.php' );
//config
require_once( 'app/config.php' );
//start app
$mod_app = new c_app;
//start db (does not connect)
$mod_db = new c_db( $mod_config['dbhost'], $mod_config['dbuser'], $mod_config['dbpass'], $mod_config['dbname'] );
//start user & session, get token
$mod_user = new c_user( $mod_db, 'cookie_thing', 'fb_app_id', 'fb_app_secret' );
$mod_session = new c_session;
$mod_token = $mod_session->generate();
//processes
if( isset( $_GET['process'] ) and isset( $map_processes[$_GET['process']] ) )
die( $mod_app->load( 'process/' . $map_processes[$_GET['process']] ) );
//loads
if( isset( $_GET['load'] ) and isset( $map_loads[$_GET['load']] ) ):
$mod_app->load( 'load/' . $map_loads[$_GET['load']] );
else:
$mod_app->load( 'load/' . $map_loads['default'] );
endif;
Loading App Files
Used to load (include) a file
Note: .php is not required on the end of the name
$mod_app = new c_app( <array of autoloaders>, <app directory, default = app/> );
$mod_app->load( 'load/file' );
Why not use include()?: the only advantage here is that this method debugs it
Autoloaders
FD Core now (v.1.2.4) uses an autoloader function stored under the c_app class
The autoloader array is an array where the keys represent class names, and the values represent the relvant .php file (with .php omitted). The class files are loaded from the app_dir (default app/) lib folder (so app/lib/ by default).
$mod_app = new c_app( array(
'class_name' => 'class_file'
), 'app_dir/' );
Database Class connection, queries and all in-between top ↑
Starting the class
Database data is normally loaded from config.php
The memcache class must be an instance of the "Memcache" class
The database class is self-protecting (explained below), and doesn't connect until required (by the first query); so calling it on every page is a non-issue.
$mod_db = new c_db( <database host>, <database name>, <mysql username>, <user password>, <memcache class, default false> );
Self Protecting?
Upon connection to the database (c_db->connect), the database runs c_db->clean() on the following sources of user input (where SQL injection is possible):
- $_GET
- $_POST
- $_COOKIE
It is important to note that this doesn't cover absolutely everything (SQL injection via faked browser-name string on $_SERVER?). To clean any other user-input/editable data, use the c_db->clean function
Cleaning/Escaping Data
Using c_db->clean()
Input values will be run via mysql_real_escape_string [except arrays], as well as trim()'d
This function accepts strings, numbers, etc to 'clean' It also accepts arrays, of any number of levels.
$data = $mod_db->clean( <array, string, number> );
Querying the Database
Takes direct SQL, just as mysql_query
Data is returned as an array
Cache will only work if a memcache class is set on c_db creation
//returns array (or false if error, error is stored in debug)
$data = $mod_db->query( <sql code>, <cache, default = false> );
Yes, I am aware of mysqli & pdo. I chose to use the basic mysql_* libary out of personal preference (it's a super-tiny bit faster too; a negligible increase).
Post-Query Data
Get the number of returned rows, or affected rows, or the last insert_id
Number of returned/affected rows
$rows = $mod_db->num_rows();
Laster inserted ID
$id = $mod_db->insert_id();
Note: Requires an auto_increment database column.
User Class login, register, ranks, permissions Top ↑
Starting the class
The first argument must be a valid c_db (or class which follows similar style and naming rules). The facebook id & secret are optional.
This class makes constant use of an OpenID class by Mewp (I'm searching for the original link).
$mod_user = new c_user( <db object>, <app cookie id, default = ''>, <facebook app id, default = ''>, <facebook app secret, default = ''> );
Session Class protects forms from cross-site attacks Top ↑
More info soon.
Template Class keeping code and html separate Top ↑
More info soon.