
CIRO est un cadre PHP MVC pour lancer des projets rapidement, il est conçu pour être simple, configurable, modulaire, découplé, extensible et léger pour faciliter la construction du code PHP mieux et facilement entretenu.
Hors de la boîte, Ciro est livré avec:
Le CIRO est livré avec un projet de modèle avec un système d'authentification simple à lancer le développement pour votre projet ou votre prototype.
Exemple en ligne du modèle de modèle Framework: https://ciro-framework.herokuapp.com
C:xampphtdocs pour Windows ou /Applications/XAMPP/xamppfiles/htdocs pour Mac.httpd.conf d'ApachePour utiliser la connexion / registre pré-préparée, et vous utilisez SQL (pas Mongo), vous devez créer la base de données et les tables dans SQL.
http://localhost/phpmyadmin et exécutez la requête dans sql_database_script.sql qui existe dans le répertoire racine. Pour utiliser la connexion / registre pré-fait, et vous souhaitez utiliser MongoDB, vous devez installer mongodb extension et MongoDB PHP Library à l'aide de compositeurs, des instructions ici. Remplacez également Models/UserRepository.php par Models.disabled.mongo.userrepository.class.php pour utiliser la version MongoDB.
Mysqli pour mysql.PDO pour les RDB prises en charge de l'OPD (s).MongoDB (PHP 7.0+).Tous configurables via les fichiers de configuration.

La structure du projet suit les spécifications PSR-4 des noms de noms.
+---Config <- Contains Configurations Files.
+---Controllers <- Contains a Dir for each Route each contains this Route's Controllers.
+---Core <- Contains Core Classes for the framework
+---Logs <- Contains Logs created by the scripts (e.g Exception Handler logs)
+---Models <- Contains Models (can be sub-directoried using namespaces using PSR-4 specs.
+---Utilities <- Contains Utility Classes.
+---Vendor <- Composer's Vendor Dir, contains autoloader code and third-party packeges.
+---Views <- Contains Views, a Dir for each route, each contains a Dir for each Controller.
| +---_FullMessages <- Contains Full Messages HTML designs.
| +---_Layouts <- Contains Layouts
+---Webroot <- Public Dir contains the single point of entry of the program, and all public assets.
Dans CIRO, une route d'URL par défaut a la structure suivante:
http://example.io/{route}/{controller}/{action}/{param1?}/{param2?}/...
Cette URL se résout à la méthode {action} de Controller {controller} dans controllers/{route} Ainsi, dans la notation PHP OOP correspond à:
App Controllers { route }{controller} -> { action } Dans Configuration Config/config.php , vous pouvez spécifier un «default_route», donc si une URL ne contient pas de route, le programme setie en fonction de l'itinéraire par défaut. Par défaut, le «default_route» est «Web». Ainsi, une URL typique utilisant la route par défaut aura la structure suivante:
http://example.io/{controller}/{action}/{param1?}/{param2?}/...
Ainsi, en PHP, la notation correspond à:
App Controllers Web {controller} -> { action }Un autre exemple:
for $id
http://example.io/{controller}/{action}/{param1}
http://example.io/ Product / View / 6800
Si l'URL ne spécifie pas {action} , le programme pour se rendre vers le «Default_Action» spécifié dans «config / config.php».
Si l'URL ne spécifie pas {controller} , le programme à réaliser vers le «Default_Controller» spécifié dans «config / config.php».
Pour ajouter une nouvelle route et y accéder à l'aide du routage par défaut, vous devez l'ajouter dans la table de routage Config/config.php .
Compte tenu de cette URL par exemple:
for $id $color
http://example.io/{controller}/{action}/{param1}/{param2}
http://example.io/ Product / View / 6800 / red
Les paramètres sont accessibles à l'intérieur de la méthode du contrôleur via $this -> params[0..*] Array, par exemple $this->params[0] maintient la valeur de {param1} dans l'URL ci-dessus.
Une autre façon d'accéder aux paramètres à l'intérieur de la méthode du contrôleur consiste à ajouter des arguments à la méthode du contrôleur lui-même. En utilisant le même exemple ci-dessus, si ProductController -> View est définie comme ceci:
class ProductController extends WebController {
public function view ( $ id , $ color = ' white ' ){
/* controller's method code here */
}
} $id aura la valeur de {param1} , $color aura la valeur de {param2} et ainsi de suite ...
Notez que si {param2} n'était pas dans l'URL, $color utilisera la valeur par défaut spécifiée, mais si {param1} n'était pas dans l'URL, le programme va rendre un message 404: Not Found car $id n'a aucune valeur par défaut spécifiée dans la méthode du contrôleur.
Les routes personnalisées vous offrent la possibilité de spécifier une URL avec un motif spécifique qui, si elle correspond à l'URL, est acheminé vers le {route}{controller}::{action} spécifié avec les paramètres spécifiés appropriés.
Les routes personnalisées peuvent être activées / désactivées dans Config/config.php .
Vous pouvez spécifier un itinéraire personnalisé pour chaque verbe http de repos, par exemple ( GET, POST, PUT, DELETE, etc ) ou spécifier un itinéraire personnalisé pour tous les verbes http possibles en utilisant:
// for GET requests
Route:: get ( $ uri , $ route , $ controller , $ action );
// same for POST, PUT, DELETE, etc requests
Route:: post (), Route:: put (), Route:: delete (), Route:: patch (), Route:: options ();
// for ALL requests
Route:: all ();Les routes personnalisées sont définies dans /config/routes.php .
Route:: get ( ' custom/route/{id}/{name}/{language?} ' , ' Web ' , ' Home ' , ' CustomRouteAction ' ); Toute URL qui correspond à custom/route/{id}/{name}/{language?} Sera acheminée vers: Route: Web Controller: Home Action: CustomRouteAction .
{ name } , les paramètres facultatifs devraient avoir un '?' À la fin de leurs noms { optinoalParam? } .$this -> params[0..*] et sont commandés respectivement à leur ordre dans l'URL.$this -> param[0] correspond à {id} , $this -> param[1] correspond à {name} , etc.La méthode d'un contrôleur d'un itinéraire personnalisé doit être définie comme suit:
class HomeController extends WebController {
public function CustomRouteAction ( $ id , $ name , $ language = ' default ' ){
/* controller's method code here */
}
} Remarque Dans l'exemple ci-dessus: {language?} Est un paramètre facultatif, les paramètres facultatifs devraient avoir un '?' À la fin de leurs noms, et devrait avoir une valeur par défaut dans la méthode du contrôleur, sinon si le param est manquant, le programme rendra un message 404: Not Found car un param optionnel n'a pas été donné et n'a pas de valeur par défaut.
Lors de la définition d'un itinéraire personnalisé, vous pouvez mettre un paramètre variable dans l' route cible, controller ou action pour créer une route personnalisée plus «générale».
Exemple:
Route:: get ( ' custom/{var_controller}/pattern/{action}/{param1} ' , ' Web ' , ' {var_controller} ' , ' {action} ' ); Toute URL qui correspond à custom/{var_controller}/pattern/{action}/{param1}
sera acheminé vers: Route: Web , Controller: {var_controller} , Action: {action} et les params n'incluront ni {var_controller} ni {action} parce qu'ils ont été utilisés dans le routage.
Donc, si une demande avec URL = personnalisé / Account / modèle / View / sherifabdlnaby est venue, elle sera acheminée vers: Route: Web , contrôleur: Account , action: View and Params [0] = ' sherifabdlnaby '
Le contrôleur est responsable du traitement des demandes des utilisateurs et du renvoi de la sortie pour l'utilisateur soit en tant que HTML pour WebControllers , soit JSONResult pour ApiControllers , soit rediriger vers une autre destination.
Le répertoire des contrôleurs doit correspondre à l'espace de noms du contrôleur et doit être le suivant Controllers{route}{ControllerName}Controller.php et à l'aide de l'espace de noms AppControllers{route} où {route} est l'itinéraire à laquelle appartient ce contrôleur.
+---Controllers
| +---Api <-- Api route dir.
| | HomeController.php <-- Home Controller for API route.
| |
| ---Web <-- Web (Default) route dir.
| AccountController.php
| HomeController.php <-- Home Controller for Web default route.
Un contrôleur a 4 variables protégées qu'il utilise:
$ params ; // array() that holds method's params
$ model ; // controller's model
$ data ; // the $data array() is what is passed to the controller's view.
$ meta ; // the $meta array() is what is passed to $layout meta section (for WebControllers Only)La sortie d'un contrôleur (et ce que l'utilisateur voit) est ce qui est renvoyé via lui.
Les contrôleurs de CIRO ont diverses fonctions à utiliser lors du retour de sortie à l'intérieur des contrôleurs pour faciliter ces tâches.
Render rendra une page Web HTML à l'aide d'une disposition, une disposition contient de l'en-tête, de la section de métadonnées, des alertes, du corps et du pied de page. La section corporelle de la disposition est déterminée en fonction du vide de la méthode du contrôleur.
La vue du contrôleur utilise le tableau $ data [] pour rendre ses éléments, et la section de métadonnées utilise le tableau $ méta [].
render ( $ layout = null , $ viewPath = null , & $ data = null , & $ meta = null );| Arg | Description | Valeur par défaut |
|---|---|---|
$layout | Spécifie la disposition de la vue utilisée pour rendre | Disposition par défaut spécifiée dans config.php |
$viewPath | Spécifie le chemin de la vue pour rendre | Afficher déterminé en fonction du nom de la méthode du contrôleur |
$data | La vue $data Array () aura également accès | Le propre dossier $data du contrôleur () |
$meta | La disposition $meta array () aura également accès | Le propre Contrôleur $meta Array () |
retourner $this->render(); Sans arguments donnés (en utilisant des valeurs par défaut) sera suffisant dans 90% des cas.
Utilisation de base de $ this -> render ();
class AccountController extends WebController {
public function View ( $ username ){
$ this -> data [ ' name ' ] = $ username ;
return $ this -> render ();
}
}RenderfulLerror et RenderfullMessage rendront une page de message / erreur personnalisée. Si un code d'état est donné dans le 2ème paramètre, le contrôleur envoie l'en-tête de code d'état HTTP correspondant et rend la vue de ce code.
function renderFullError( $ message , $ statusCode = null , $ layout = null );
function renderFullMessage( $ message , $ statusCode = null , $ layout = null );| Arg | Description | Valeur par défaut |
|---|---|---|
$message | Un message à rendre dans la vue. | Aucun (champ requis) |
$statusCode | Code d'état HTTP | nul |
$layout | Spécifie la disposition de la vue utilisée pour rendre | Disposition par défaut spécifiée dans config.php |
Utilisation de base de $ this -> RenderfulLerror () / RenderfullMessage ();
class AccountController extends WebController {
public function View ( $ username ){
if ( /* User Found */ )
return $ this -> render ();
else
return $ this -> renderFullError ( ' User not found! ' , 404 );
}
}Si une exception a été soulevée lors de l'exécution du script, le framework rendra une page d'erreur personnalisée d'erreur de serveur interne de 500.
Lorsque vous retournez $ this -> return () à partir de l'absence de sortie d'un contrôleur n'est envoyé à l'utilisateur, mais l'utilisateur est redirigé vers l'URL donnée.
function redirect( $ path );| Arg | Description | Valeur par défaut |
|---|---|---|
| $ chemin | Un chemin Relative ou Full à rediriger vers | Aucun (champ requis) |
Utilisation de base de $ this -> redirect ();
class AccountController extends WebController {
public function Login ( $ username , $ password ){
if ( /* Login Success */ )
return $ this -> redirect ( ' / ' ); // redirect to homepage.
else
return $ this -> renderFullMessage ( ' Incorrect Username or Password ' , 401 );
}
}Vérifiez si l'utilisateur est / n'est pas connecté, redirigez vers la page d'accueil / la connexion sinon.
Ces fonctions ne sont pas utilisées par l'instruction RETOUR, mais elle arrête le script s'ils redirigent l'utilisateur, ce qui signifie que tout code inférieur à ces fonctions ne sera pas exécuté si leur validation est fausse;
function verifyLoggedIn();
function verifyNotLoggedIn();Utilisation de base de $ this -> VerifyLoggedIn () / VerifyNotLoggedIn ();
class AccountController extends WebController {
public function Login ( $ username , $ password ){
$ this -> verifyNotLoggedIn (); //Redirects to Homepage if user is already logged in.
if ( /* Login Success */ )
return $ this -> redirect ( ' / ' );
else
return $ this -> renderFullMessage ( ' Incorrect Username or Password ' , 401 );
}
} La classe de session est une classe extensible qui gérera l'utilisation de SESSION $ _ dans les programmes pour appliquer le principe de responsabilité unique.
/* Save Parameters to $_SESSION, use for Login */
public static function saveLoginSession( $ _id , $ username );
/* Return TRUE if user is logged On */
public static function isLoggedIn ();
/* Unset and Destroy current Session, use for logout */
public static function destroyLoginSession ();
/* Add Error Alerts to be rendered to user when controller's $this -> render() is called */
public static function addErrorAlert ( $ errorAlert );
/* Add Warning Alerts to be rendered to user when controller's $this -> render() is called */
public static function addWarningAlert ( $ warningAlert );
/* Add info Alerts to be rendered to user when controller's $this -> render() is called */
public static function addInfoAlert ( $ infoAlert );
/* Add success Alerts to be rendered to user when controller's $this -> render() is called */
public static function addSuccessAlert ( $ successAlert );Les alertes sont des messages flash enregistrés dans les sessions de l'utilisateur, les alertes peuvent ensuite être montrées à l'utilisateur soit en rendant en HTML, soit en les codant en JSON au cas d'une API.
Les alertes peuvent être utilisées pour montrer des erreurs sur la validation du formulaire, ou un message si un processus a réussi ou échoué.
Les alertes ont leur propre section dans n'importe quelle disposition, Controller -> Render () Fonction rendra toutes les alertes stockées en session utilisateur.
Il existe 4 types d'alertes:

Une disposition est la structure de la page Web HTML, elle se compose de 5 sections
| Section | Description |
|---|---|
| méta | Cette section rend les balises de métadonnées HTML pour les balises de titre, DESC et SEO. les métadonnées passées et remplies par le contrôleur et sont accessibles dans le Array $ Meta () |
| tête | Cette section rend l'en-tête de la page |
| alertes | Cette section rend les alertes stockées dans la session de l'utilisateur |
| contenu | Cette section rend la partie principale de la page et a ses données adoptées et remplies par le contrôleur |
| pied de page | Cette section rend le pied de page de page |
+---Views
| ---_Layouts
| ---default <-- Layout root directory.
| | | footer.html
| | | header.html
| | | layout.html
| | | meta.html
| | ---alerts <-- alerts directory.
| | errors.html
| | infos.html
| | successes.html
| | warnings.html
| ---anotherLayout
Layout.html est le fichier final rendu lors du rendu de la disposition, c'est la structure qui va sur laquelle, etc. et tout CSS / JS utilisé dans cette disposition doivent être inclus dans la mise en page.html tels que Bootstrap CSS et JS
<!DOCTYPE html >
< html lang =" en " >
< head >
< ?= $data['meta'] ? >
< link rel =" stylesheet " href =" /bootstrap/css/bootstrap.min.css " >
</ head >
< body >
< ?= $data['header'] ? >
< ?= $data['alerts'] ? >
< ?= $data['content'] ? >
< ?= $data['footer'] ? >
< script src =" /bootstrap/js/bootstrap.min.js " > </ script >
</ body >
</ html > 
Une vue est la sortie de l'action d'un contrôleur Web, une vue a un tableau d'assocation de données $ qui est passé par le contrôleur, il est utilisé pour transmettre des données entre le contrôleur et la vue. L'emplacement de la vue doit correspondre à la structure du chemin du contrôleur / de l'espace de noms.
View d'action du Account Controller dans la route Web +---Controllers
| +---Api
| | HomeController.php
| |
| ---Web
| AccountController.php <-- Account Controller of Web route in ControllersWeb
| HomeController.php
|
+---Views
| +---Web
| | +---Account <-- Account Controller View Dir in ControllerWebAccount
| | | Index.html
| | | Login.html
| | | Register.html
| | | View.html <-- The View for action 'View', of 'Account Controller' in the 'Web' Route
| | |
| | ---Home
| | About.html
| | Index.html
Config/config.php .Les classes d'assistance de base de données sont utilisées pour obtenir une instance singleton pour les connexions de base de données, où les informations d'identification de connexion sont stockées dans des fichiers de configuration.
| Classe | Extension | Description |
|---|---|---|
| Dbpdo | PDO | Une classe singleton pour l'extension PDO DB, l'OPD peut être utilisé pour se connecter à divers RDB comme MySQL, MARIADB ou PostgreSQL, les informations d'identification de connexion définies sur Configpdo.php et activées sur Config/config.php |
| Dbsql | Mysqli | Une classe singleton pour l'extension mysqli, les informations d'identification de connexion pour mysql définies sur Configmysqli.php et activées sur Config/config.php |
| Dbmongo | mongodb utilisant MongoDB PHP Library (PHP 7.0+) | Une classe singleton pour une connexion de la bibliothèque PHP MongoDB qui est construite autour de l'extension mongodb de bas niveau, les informations d'identification sont stockées sur Configmongo.php et activées sur Config/config.php |
mongodb et MongoDB PHP Library , qui nécessite tous deux PHP 7.0+ composer require mongodb/mongodbCiro PHP Framework est sous la licence MIT, vous pouvez afficher la licence ici.