xdrm-framework

Description

xdrm-framework is a tool that wraps my framework and all it's component's versions. It allows to build a web framework's base with chosen modules and their versions.

1. Build a project

To use the xdrm-framework's project builder, just open a linux terminal and type :

1. ./xfw packages - to display the available modules
2. ./xfw install {packageName}:1.2 - to install a package and its version (1.2 here)
3. ./xfw remove {packageName} - to disable a module
4. ./xfw build {projectRoot} - will create your project in the folder {projectRoot}
5. ./xfw init - to remove all enabled modules

2. Project's file structure

xdrm-framework is based on all in config so you will have this structure :

• folder /build which contains framework's modules (core + data).
• folder /public_html which contains visible content (html, css, js).
• folder /config which contains the modules' config files (mainly json).
• file /autoloader.php which will auto-load the components.

Note: In every php file you want to use framework's classes, you have to begin your file by :

<?php
	  /* [1] load the autoloader with correct path */
	  require_once '../autoloader.php';

	  /* [2] then you can load your classes */
	  use api\core\Request;  // ex1: api request manager
	  use error\core\Error;  // ex2: error manager
	  use error\core\Err;    // ex3: error codes

	  /* [3] and use them as long as you want without namespace */
	  $request  = new Request('module/method', ['id_user' => 10]);
	  $response = $request->dispatch();

	  if( $response->error->get() === Err::Success )
		  echo "All is going right!\n";

Note: Some global constants are created into the autoloader so they are accessible from any file which loads the autoloader:

• __BUILD__ - The absolute build folder path
• __PUBLIC__ - The absolute public_html folder path
• __ROOT__ - The absolute root path (project root)
• __CONFIG__ - The absolute config folder path

3. Modules

3.1 API - self-managed API

How to use

In order to use the API, you must begin by writting your "methods" in the configuration file located at /config/modules.json. In order to be understood, lets call module a group of methods, and method a function which outputs data from input parameters.

Configuration format

{

	"{module_name}": {

		"{http_method}::{method_name}": {
			"description": "{method_description}",
			"permissions": ["{method_perm}"],
			"options": { "download": "{is_downloadable}" },
			"parameters": {
				"{name_param}": { "description": "{desc_param}", "type": "{type_param}", "optional": "{is_optional}" }
			},
			"output": {
				"{name_output}": { "description": "{desc_output}", "type": "{type_output}" }
			}
		}

	}
}

variable	description	exemple
{module_name}	alphanumeric module name	"publications"
{http_method}	uppercase HTTP method	"POST"
{method_name}	alphanumeric method name	"article"
{method_description}	textual description	"Returns a specific article"
{method_perm}	permission array	["poster", "admin", "user"]
{is_downloadable}	If you want this method to return a file	true, false
{name_param}	Your param's name	"id_article"
{desc_param}	Your param's description	"Wanted article's id"
{type_param}	Your param's type (cf. Checker)	"Wanted article's type"
{is_optional}	Whether to make your param required	true, false
{name_output}	Your output's name	"article"
{desc_output}	Your output's description	"Article content"

Implementation TODO

Classes (advanced)

The API is managed through 5 classes :

1. Request - is the core of the module
2. Response - renders and manages the responses
3. Authentification - manages the authentification part (it has to be over written for each case)
4. Checker - manages auto checked parameters' types
5. ModuleFactory - to instanciate each module, transparent to the user

[3.2] error - error system

[3.3] database - database wrapper and repository manager

[3.4] orm - sql orm

[3.5] router - apache2 router

[3.6] lightdb - fast key-value storage