
O CIRO é uma estrutura de PHP do MVC para iniciar projetos rapidamente, foi projetado para ser simples, configurável, modular, desacoplado, extensível e leve para facilitar a construção do código PHP melhor e facilmente mantido.
Fora da caixa CIRO vem com:
O CIRO vem com um projeto de modelo com um sistema de autenticação simples para o desenvolvimento do Projecting ou Prototype.
Exemplo on-line do projeto de modelo de estrutura: https://ciro-framework.herokuapp.com
C:xampphtdocs for windows ou /Applications/XAMPP/xamppfiles/htdocs para Mac.httpd.conf do Apache do Xampp para o diretório do CIRO, consulte Instruções: Aqui.Para usar o login/registro pré-fabricado e você está usando o SQL (não o Mongo), você deve criar o banco de dados e as tabelas no SQL.
http://localhost/phpmyadmin e execute a consulta em sql_database_script.sql que existe no diretório raiz. Para usar o login/registro pré-fabricado e você deseja usar o MongoDB , você deve instalar mongodb extension e MongoDB PHP Library usando o compositor, instruções aqui. Substitua também Models/UserRepository.php com Models.disabled.mongo.userrepository.class.php para usar a versão MongoDB.
Mysqli para mysql.PDO para RDBMS (s) com suporte de PDO.MongoDB (Php 7.0+).Tudo configurável através dos arquivos de configuração.

A estrutura do projeto segue as especificações do PSR-4 namim.
+---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.
No CIRO, uma rota de URL padrão possui a seguinte estrutura:
http://example.io/{route}/{controller}/{action}/{param1?}/{param2?}/...
Este URL resolve o método {action} do controlador {controller} nos controllers/{route} , portanto, na notação php oop, corresponde a:
App Controllers { route }{controller} -> { action } Na configuração Config/config.php , você pode especificar um 'default_route', portanto, se um URL não contiver uma rota, o programa irá rotear de acordo com a rota padrão. Por padrão, o 'default_route' é 'web'. Portanto, um URL típico usando a rota padrão terá a seguinte estrutura:
http://example.io/{controller}/{action}/{param1?}/{param2?}/...
Então, na notação Php OOP, corresponde a:
App Controllers Web {controller} -> { action }Outro exemplo:
for $id
http://example.io/{controller}/{action}/{param1}
http://example.io/ Product / View / 6800
Se o URL não especificar {action} , o programa para rotear para o 'default_action' especificado em 'config/config.php'.
Se o URL não especificar {controller} , o programa para rotear para o 'default_controller' especificado em 'config/config.php'.
Para adicionar uma nova rota e acessá -la usando o roteamento padrão, você deve adicioná -lo na tabela de roteamento Config/config.php .
Dado este URL, por exemplo:
for $id $color
http://example.io/{controller}/{action}/{param1}/{param2}
http://example.io/ Product / View / 6800 / red
Os parâmetros são acessíveis dentro do método do controlador via $this -> params[0..*] Array, por exemplo $this->params[0] mantém o valor de {param1} no URL acima.
Outra maneira de acessar params dentro do método do controlador é adicionar argumentos ao próprio método do controlador. Usando o mesmo exemplo acima, se ProductController -> View for definido assim:
class ProductController extends WebController {
public function view ( $ id , $ color = ' white ' ){
/* controller's method code here */
}
} $id terá o valor de {param1} , $color terá o valor de {param2} e assim por diante ...
Observe que se {param2} não estivesse no URL, $color usará o valor padrão especificado, no entanto, se {param1} não estivesse no URL, o programa renderizará uma mensagem 404: Not Found porque $id não possui valor padrão especificado no método do controlador.
As rotas personalizadas oferecem a possibilidade de especificar um URL com um padrão específico que, se corresponder, o URL é roteado para o {route}{controller}::{action} com os parâmetros especificados adequados.
As rotas personalizadas podem ser ativadas/desativadas em Config/config.php .
Você pode especificar uma rota personalizada para cada verbo http de repouso, por exemplo ( GET, POST, PUT, DELETE, etc ) ou especificar uma rota personalizada para todos os verbos HTTP possíveis usando:
// 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 ();As rotas personalizadas são definidas em /config/routes.php .
Route:: get ( ' custom/route/{id}/{name}/{language?} ' , ' Web ' , ' Home ' , ' CustomRouteAction ' ); Qualquer URL que corresponda custom/route/{id}/{name}/{language?} Será roteado para: rota Web controlador da web Home ação inicial: CustomRouteAction .
{ name } , params opcionais devem ter um '?' No final de seus nomes { optinoalParam? } .$this -> params[0..*] e são ordenados, respectivamente, à ordem deles no URL.$this -> param[0] corresponde a {id} , $this -> param[1] corresponde a {name} , etc.O método de um controlador de uma rota personalizado deve ser definido da seguinte forma:
class HomeController extends WebController {
public function CustomRouteAction ( $ id , $ name , $ language = ' default ' ){
/* controller's method code here */
}
} Observe no exemplo acima: {language?} É um parâmetro opcional, os parâmetros opcionais devem ter um '?' No final de seus nomes, e deve ter um valor padrão no método do controlador, caso contrário, se o parâmetro estiver ausente, o programa renderizará uma mensagem 404: Not Found porque um parâmetro opcional não foi fornecido e não possui valor padrão.
Ao definir uma rota personalizada, você pode colocar um parâmetro variável na route de destino, controller ou action para criar uma rota personalizada mais 'geral'.
Exemplo:
Route:: get ( ' custom/{var_controller}/pattern/{action}/{param1} ' , ' Web ' , ' {var_controller} ' , ' {action} ' ); Qualquer URL que corresponda custom/{var_controller}/pattern/{action}/{param1}
será roteado para: rota: Web , controlador: {var_controller} , ação: {action} e params não incluirão nem {var_controller} nem {action} porque foram usados no roteamento.
Portanto, se uma solicitação com URL = Custom / Account / Pattern / View / sherifabdlnaby veio, será roteado para: Rota: Web , Controlador: Account , Ação: View e Params [0] = ' sherifabdlnaby '
O Controller é responsável pelo processamento de solicitações dos usuários e devolvendo a saída para o usuário como um HTML para WebControllers ou JSONResult para ApiControllers ou redireciona para outro destino.
O diretório dos controladores deve corresponder ao espaço de nome do controlador e deve ser o seguinte Controllers{route}{ControllerName}Controller.php e usando o espaço de nome AppControllers{route} onde {route} é a rota para onde esse controlador pertence.
+---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.
Um controlador possui 4 variáveis protegidas que utiliza:
$ 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)A saída de um controlador (e o que o usuário vê) é o que é retornado através dele.
Os controladores no CIRO têm várias funções a serem usadas ao devolver a saída dentro dos controladores para facilitar essas tarefas.
Render fará uma página da web html usando um layout, um layout contém cabeçalho, seção de metadados, alertas, corpo e rodapé. A seção corporal do layout é determinada de acordo com o método ViewPath do controlador.
A exibição do controlador usa a matriz $ data [] para renderizar seus elementos, e a seção de metadados usa a matriz $ meta [].
render ( $ layout = null , $ viewPath = null , & $ data = null , & $ meta = null );| Arg | Descrição | Valor padrão |
|---|---|---|
$layout | Especifica o layout de visualização usado para renderizar | Layout padrão especificado em config.php |
$viewPath | Especifica o caminho para a vista renderizar | Visualização determinada de acordo com o nome do método do controlador |
$data | A visualização $data () também terá acesso | A própria matriz $data do controlador () |
$meta | O layout $meta -matriz () também terá acesso | A própria matriz $meta do controlador () |
retornar $this->render(); Sem nenhum argumento (usando valores padrão), será suficiente em 90% dos casos.
Uso básico de $ this -> render ();
class AccountController extends WebController {
public function View ( $ username ){
$ this -> data [ ' name ' ] = $ username ;
return $ this -> render ();
}
}Renderfullerror e RenderfullMessage renderizarão uma página de mensagem/erro personalizada. Se um código de status for fornecido no 2º parâmetro, o controlador enviará o cabeçalho do código de status HTTP correspondente e renderizar a visualização deste código.
function renderFullError( $ message , $ statusCode = null , $ layout = null );
function renderFullMessage( $ message , $ statusCode = null , $ layout = null );| Arg | Descrição | Valor padrão |
|---|---|---|
$message | Uma mensagem a ser proferida na vista. | Nenhum (campo necessário) |
$statusCode | Código de status HTTP | nulo |
$layout | Especifica o layout de visualização usado para renderizar | Layout padrão especificado em config.php |
Uso básico 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 );
}
}Se alguma exceção foi aumentada durante a execução do script, a estrutura renderizará uma página de erro personalizada de erro de erro interno de 500 servidor.
Ao retornar $ this -> return () da saída de um controlador é enviado ao usuário, mas o usuário é redirecionado para o URL fornecido.
function redirect( $ path );| Arg | Descrição | Valor padrão |
|---|---|---|
| $ caminho | Um caminho Relative ou Full a ser redirecionado para | Nenhum (campo necessário) |
Uso básico 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 );
}
}Verifique se o usuário não está conectado, redirecione para a página inicial/login, se não.
Essas funções não são usadas pela declaração de retorno, no entanto, ele interrompe o script se estiver redirecionando o usuário, o que significa que qualquer código abaixo dessas funções não será executado se a validação for falsa;
function verifyLoggedIn();
function verifyNotLoggedIn();Uso básico 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 );
}
} A classe de sessão é uma classe extensível que gerenciará o uso de $ _ SESSION nos programas para aplicar o princípio de responsabilidade única.
/* 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 );Os alertas são mensagens flash salvas nas sessões do usuário, os alertas podem ser mostrados ao usuário, renderizando como um html ou codificando-os no JSON no caso de uma API.
Os alertas podem ser usados para mostrar erros sobre validação de formulário ou uma mensagem se um processo tiver sucesso ou falhar.
Os alertas têm sua própria seção em qualquer layout, o controlador -> render () função renderizará quaisquer alertas armazenados na sessão do usuário.
Existem 4 tipos de alertas:

Um layout é a estrutura da página da web html, consiste em 5 seções
| Seção | Descrição |
|---|---|
| Meta | Esta seção renderiza as tags de metadados HTML para tags, tags DESC e SEO. Metadados passados e preenchidos pelo controlador e são acessíveis na matriz $ meta () |
| cabeçalho | Esta seção renderiza o cabeçalho da página |
| Alertas | Esta seção renderiza alertas armazenados na sessão do usuário, se houver |
| contente | Esta seção renderiza parte principal da página e tem seus dados passados e preenchidos pelo controlador |
| rodapé | Esta seção renderiza o rodapé da página |
+---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 é o arquivo final renderizado ao renderizar o layout, é a estrutura da qual passa sobre a qual, etc., e qualquer CSS/JS usado neste layout deve ser incluído no layout.html como bootstrap css e 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 > 
Uma visualização é a saída da ação de um controlador da Web, uma visualização possui uma matriz $ Data Assoc, que é passada pelo controlador, é usada para passar dados entre o controlador e a exibição. O local da visualização deve corresponder à estrutura do caminho do controlador/namespace.
View de ação do Account Controller na rota 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 .As classes auxiliares do banco de dados são usadas para obter uma instância de singleton para conexões de banco de dados, onde as credenciais de conexão são armazenadas em arquivos de configuração.
| Aula | Extensão | Descrição |
|---|---|---|
| Dbpdo | PDO | Uma aula de singleton para extensão de DB DB, PDO pode ser usada para se conectar a vários RDBMs como MySQL, Mariadb ou PostgreSQL, credenciais de conexão definidas em Configpdo.php e ativadas em Config/config.php |
| Dbsql | Mysqli | Uma classe singleton para extensão MySQLI, credenciais de conexão para MySQL definido em Configmysqli.php e ativado em Config/config.php |
| Dbmongo | mongodb usando MongoDB PHP Library (Php 7.0+) | Uma aula de singleton para uma conexão da biblioteca PHP do MongoDB, construída em torno da extensão mongodb de baixo nível, as credenciais são armazenadas em Configmongo.php e ativadas em Config/config.php |
mongodb e MongoDB PHP Library , que requer php 7.0+ composer require mongodb/mongodbO CIRO PHP Framework está sob a licença do MIT, você pode visualizar a licença aqui.