[Agora-generale] Fw: [spip-dev] les métiers dans Agora

[Erwan LE BESCOND]

BoOz wrote:

>Bonjour à tous,
>
>Invité par Erwan à poursuivre une discussion initiée sur spip_dev ici, je
>reprends le fil là ou nous en étions :
>
>  
>
Super

>>ps : pas évident d'installer agora sur un pc windows avec easyphp :o(
>>du coup je n'ai regardé que le code : c'est quoi tous ces métiers dedans ?
>>    
>>
Je suppose que tu parles du répertoire ecrire/include/bd/ ...

Avant de parler de ce répertoire, je vais rapidement parler de 
l'arborescence du répertoire "include" ajouté dans "ecrire/". Ce 
répertoire stocke l'ensemble des modules apportés par SPIP-AGORA.

authorization/      Le module de gestion des droits utilisateurs de 
Spip-AGORA.
bd/ Ce répertoire contient des classes métiers de Spip-AGORA.
clevermail/        Le module de newsletter de Spip-AGORA.
fpdf/        Le module de génération de pdf.
NestedSet/      Ce répertoire contient une réimplémentation du package 
PEAR::DB_NestedSet afin de fournir une gestion de l'arborescence de mot 
clé respectant la norme SQL 92.
sevenseas/      L'abstraction de moteur d'indexation externe de Spip-AGORA.


Revenons à ta question C'est quoi les metiers?

Dans Spip-AGORA, la notion de métier correspond plus précisement aux 
différents éléments composant le coeur de Spip et donc de Spip-AGORA. 
Par exemple un article, les auteurs, les rubriques sont des élèments 
métier dans Spip-AGORA.

L'objectif de Spip-AGORA est de fournir une architecture technique 
instanciable rapidement dans divers environnements techniques. Plus 
concrétement, en prenant la problématique de stockage des données, 
Spip-AGORA fournit une abstraction qui lui permet d'être utilisé par 
exemple avec une base de données MySql, une base de données Oracle ou un 
fichier texte formaté comme on le souhaite (pour les plus fous).

Dans les faits Spip-AGORA propose une implémentation de la couche 
d'accès aux données respectant la norme SQL92 lui permettant d'être 
utilisé avec n'importe quelle base de données respectant cette norme.


Le principe de l'abstraction aux niveau de l'accès aux données ou 
abstraction de bases de données est le suivant:


---> Abstraction technique

L'abstraction technique a pour but de permettre la connexion de 
l'application à n'importe quelle base de données, en utilisant une API 
standardisée. Elle permet donc un premier niveau d'abstraction. 
Cependant, cette couche seule ne suffit pas, puisqu'elle ne gère que les 
échanges d'informations entre le tiers données et le tiers applicatif. 
Elle ne permet pas en effet de transformer des requêtes SQL en requêtes 
compréhensibles par n'importe quelle base de données. Par exemple, une 
requête utilisant des fonctionnalités spécifiques MySQL ne sauraient 
être traduites par cette couche pour fonctionner sur n'importe quelle 
autre base.

C'est pour cela qu'au dessus de cette couche purement technique, se 
trouve une couche métier, dont le rôle est principalement de 
standardiser les requêtes SQL, en les abstrayant derrière une API unifiée.

La solution logicielle employée pour cette couche d'abstraction 
technique est PEAR ::DB, qui présente l'avantage de fonctionner avec un 
très grand nombre de bases de données différentes, et de limiter pour 
certains cas précis l'utilisation de commandes SQL spécifiques.


--> Abstraction métier

La couche d'abstraction métier est la couche appelée depuis le coeur 
applicatif de Spip-AGORA lorsqu'il est nécessaire d'effectuer une 
requête sur la base de données utilisée. On y retrouve ainsi une 
modélisation de tous les objets métiers utilisés par Spip-AGORA, parmi 
lesquels on peut citer les articles, brèves, rubriques, auteurs, etc.

C'est au sein de cette couche que la notion de « pilote [4] » fait sens. 
En effet, c'est dans cette couche qu'est regroupé l'ensemble des 
requêtes SQL. Donc, lorsqu'une requête standard n'est pas supportée par 
une base de données, il s'agit de redéfinir une requête qui, elle, 
fonctionne correctement dans ce contexte.

L'utilisation d'une méthodologie objet dans la réalisation de cette 
couche permet de faciliter l'écriture de ces drivers. En effet, les 
mécanismes d'héritage et de polymorphisme permettent à l'auteur d'un 
pilote de n'avoir à écrire uniquement les quelques méthodes contenant 
des requêtes non supportées.


Voici un exemple d'utilisation de l'abstraction métier dans Spip-AGORA:

Exemple :

/* CODE SPIP */
spip_query("UPDATE spip_articles SET date_modif=NOW(), 
auteur_modif=$connect_id_auteur WHERE id_article=$id_article");

/* CODE AGORA */
$articleMetier = &recuperer_instance_article();
$loadOK = $articleMetier->load($id_article);
if(PEAR::isError($loadOK)) {
        die($loadOK->getMessage());
}
$maDate = new Date();
$articleMetier->setModificationDate($maDate->getDate());
$articleMetier->setAuteurModif($connect_id_auteur);
$updateOK = $articleMetier->update();
if(PEAR::isError($updateOK)) {
        die($updateOK->getMessage());
}








J'espère que ces rapides explications répondront à la question Pourquoi 
AGORA?

Erwan
-------------- section suivante --------------
Une pièce jointe HTML a été enlevée...
URL: http://lists.adullact.net/pipermail/agora-generale/attachments/20040413/053995eb/attachment.html