Base de connaissance Apps Panel

S’abonner

Architecture et fonctions natives

1. Arborescence de l'application

Pour utiliser des WS v4, une application doit se composer d'un dossier ./classes dans lequel il est convenu d'inclure ensuite différents sous-dossiers :

  • ./app contenant les classes utiles à l'exécution des WS ("front-office")
  • ./cli contenant les classes de WS exécutables par PHP-CLI
  • ./cron contenant les classes propres à l'exécution de tâches de type CRON

Les dossiers ci-dessus correspondent aux namespaces dans lesquelles les classes présentes devront être déclarées.

2. Les classes WS "modules"

2.1 Arborescence, namespaces

Le dossier ./app est composé de différents éléments :

On y trouve d'abord les classes de WS dans des dossiers versionnés ./app/v(n)/modulesn = numéro de version. Par représentation de ce versioning, les classes par exemple présentes dans ./app/v2/modules appartiendront au namespace \App\v2\Modules.

L'exécution d'un WS v4 utilise cependant la version 1 du dit-WS sauf mention contraire. Ainsi, la version 1 est implicite autant en termes de dossier que de namespace, ce qui se traduit par la présence d'un dossier ./app/modules (et non ./app/v1/modules) dont les classes seront inscrites dans le namespace \App\Modules (et non \App\v1\Modules).

Les fichiers de WS versionnés ultérieurement pourront choisir d'étendre ou non les classes de versions précédentes selon des contraintes de maintenabilité et/ou de refactorisation.

Peuvent également se trouver dans ce dossier des classes qui n'ont pas vocation à être instanciées par un appel de WS (Tools.php (\App\v(n)\Tools) ou Rest.php (\App\v(n)\Rest) par exemple).

Ces critères s'appliquent de la même manière au dossier ./cli et son namespace \Cli.

Le dossier ./cron est pour sa part moins contraignant puisqu'il dépend de l'exécution d'une tâche PHP par la crontab. Il est fortement conseillé depuis mai 2016 de lui faire directement exécuter des WS v4 \Cli par PHP-CLI afin de bénéficier de l'ensemble des fonctionnalités offertes par le core v4.

De manière générale et pour s’assurer un fonctionnement optimal il est de rigueur de respecter les guidelines suivantes :

  • Nommer les dossiers en lowercase
  • Nommer les fichiers et classes WS en Uppercase, de préference au pluriel pour les formats d’URL Rest

2.2 Héritage

\Modules\Elements est la classe de base du core v4 et met à disposition une méthode get qui permet de simplifier l'utilisation de "SELECT" MySQL de base :

namespace Modules;
/**
* Class Elements
* @package Modules
*/

class Elements
{
   protected static $table = 'data_elements';
   protected static $primary_key = 'id_element';
   protected static $fields = array('id', 'a.`active`', 'a.`date_create`',);
   protected static $join = array();
   protected static $groupby;
   protected static $orderby = 'a.`date_create` DESC';
   protected static $limit = 30;
}

Ainsi, en l'étendant et personnalisant ses propriétés, il devient possible de retourner une liste d'éléments ou un élément correspondant en une ligne de code :

namespace App\Modules;
/**
* Class MyClass
* @package App\Modules
*/

class MyClass extends \Modules\Elements
{
   protected static $table = 'data_table';
   protected static $primary_key = 'id_table';
   protected static $limit = 10;

   /**
    * @param WSController $controller
    * @param array $params
    * @return mixed
    */
   public static function get(WSController $controller, $params = array())
   {
       return parent::get($controller, $params);
   }
}

Le core v4 met à disposition quelques classes de base telles que \Modules\Infos ou \Modules\News, qui étendent eux-mêmes de \Modules\Elements.

Cependant aucune de ces classes n'est directement exposée et elles doivent être étendues côté app pour pouvoir être utilisées :

namespace App\Modules;
/**
* Class News
* @package App\Modules
*/

class News extends \Modules\News
{

   /**
    * @param WSController $controller
    * @param array $params
    * @return mixed
    */
   public static function get(WSController $controller, $params = array())
   {
       return parent::get($controller, $params);
   }
}

Il est à noter qu'il est tout à fait possible d'exécuter son propre code et donc ses propres requêtes dans ses méthodes WS.

2.3 Méthodes HTTP et méthodes de classe

Les WS v4 étant exposés façon REST, ils sont accessibles par l'utilisation de diverses méthodes HTTP et d'une sémantique bien précise.

Ainsi et selon la classe \App\Modules\Infos présentée ci-dessus :

- GET /news tentera d'exécuter \App\Modules\News::get(), lequel renverra la liste des données présentes dans la table "data_news"

- GET /news/1 tentera d'exécuter \App\Modules\News::get(), lequel renverra l'entrée dans la table "data_news" pour laquelle "id_news" vaut "1"

Par mesure de précaution il n'existe pas de traitement par défaut pour les autres méthodes HTTP. Il est ainsi requis d'exécuter soi-même les différents traitements au POST ou PATCH par exemple.

Le paramètre $controller de chaque méthode WS contient l'instance courante de la classe contrôleur de l'exécution WS.

Ce dernier expose différentes méthodes pour faciliter le développement :

- getPage permet de récupérer la page courante (?page=n)

- getUniq permet de connaître l'identifiant unique de ce contrôleur

Le paramètre $params contient la liste des paramètres composant la query string de la requête.

Les données envoyées de $_POST ou php://input sont elles disponibles par l'utilisation de la classe \Lib\DataRequest.

Cet article vous a-t-il été utile ?
Utilisateurs qui ont trouvé cela utile : 0 sur 0
Vous avez d’autres questions ? Envoyer une demande