Raccourcis : Contenu - rubriques - sous rubriques
FR

Piste : 1.3

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision
Révision précédente
Prochaine révisionLes deux révisions suivantes
jelix_vs_copix [2006/03/21 07:45] – (old revision restored) 127.0.0.1jelix_vs_copix [2006/11/08 11:02] – (old revision restored) 127.0.0.1
Ligne 1: Ligne 1:
 ====== Quel est le rapport entre Jelix et Copix ====== ====== Quel est le rapport entre Jelix et Copix ======
  
-Jelix est un framework réalisé par Laurent Jouanneau, qui fut un des développeurs principaux du framework Copix. Jelix réutilise certains composants et concepts de la version 2.3dev20050901 (septembre 2005) de Copix. Le coeur a cependant été réécrit presque entièrement. Jelix va donc plus loin qu'un simple fork de Copix.+Jelix est un framework réalisé par [[laurent-jouanneau|Laurent Jouanneau]], qui fut un des développeurs principaux du framework Copix. Jelix réutilise certains composants et concepts de la version 2.3dev20050901 (septembre 2005) de Copix. Le coeur a cependant été réécrit presque entièrement. Jelix va donc plus loin qu'un simple fork de Copix.
  
 Voici les nouveautés et différences qu'apporte Jelix par rapport à Copix 2.3dev20050901 (cette liste est destinée aux personnes connaissant déjà Copix). Voici les nouveautés et différences qu'apporte Jelix par rapport à Copix 2.3dev20050901 (cette liste est destinée aux personnes connaissant déjà Copix).
Ligne 24: Ligne 24:
      * Il y a un controle sur le type contenu d'une réponse en fonction de la requête. Par exemple, on ne peut pas générer du html s'il s'agit d'une requête formatée en XMLRPC. La réponse devra être en XMLRPC. Il y a ainsi des objets de traitements de requêtes dediés à des requêtes spécifiques et n'autorisant que des réponses spécifiques.      * Il y a un controle sur le type contenu d'une réponse en fonction de la requête. Par exemple, on ne peut pas générer du html s'il s'agit d'une requête formatée en XMLRPC. La réponse devra être en XMLRPC. Il y a ainsi des objets de traitements de requêtes dediés à des requêtes spécifiques et n'autorisant que des réponses spécifiques.
      * Les erreurs techniques qui pourraient apparaître (par trigger_error ou exceptions) sont générées dans le format approprié à la requête/réponse ! (pas de retour d'erreur formatées en HTML quand on attend du JSONRPC par exemple)      * Les erreurs techniques qui pourraient apparaître (par trigger_error ou exceptions) sont générées dans le format approprié à la requête/réponse ! (pas de retour d'erreur formatées en HTML quand on attend du JSONRPC par exemple)
-     * les plugins de templates sont dédiés à un format de sortie spécifique. On ne peut donc pas utiliser un format +     * les plugins de templates sont dédiés à un format de sortie spécifique. 
-   * Les sélecteurs : la syntaxe a changée "type:module~ressource" ou "module~ressource". Il y a beaucoup plus de type de sélecteurs et les classes correspondantes à chaque sélecteur permettent de récupérer le chemin correspondant (les chemins ne sont plus calculés à divers endroit du framework comme c'est le cas dans Copix)+   * Les sélecteurs : la syntaxe a changé "type:module~ressource" ou "module~ressource". Il y a beaucoup plus de type de sélecteurs et les classes correspondantes à chaque sélecteur permettent de récupérer le chemin correspondant (les chemins ne sont plus calculés à divers endroit du framework comme c'est le cas dans Copix)
    * Grâce à certains sélecteurs il est possible de proposer un fichier alternatif à un original. Cela permet ainsi de ne pas toucher au code d'un module. Ainsi, on peut redéfinir les templates, les daos, les locales.    * Grâce à certains sélecteurs il est possible de proposer un fichier alternatif à un original. Cela permet ainsi de ne pas toucher au code d'un module. Ainsi, on peut redéfinir les templates, les daos, les locales.
    * Il n'y a plus de "niveau projet"    * Il n'y a plus de "niveau projet"
    * Une application peut utiliser des modules se situant dans des répertoires différents. On peut ainsi mutualiser des modules entre plusieurs applications. Idem pour les plugins du coordinateur et les plugins de templates.    * Une application peut utiliser des modules se situant dans des répertoires différents. On peut ainsi mutualiser des modules entre plusieurs applications. Idem pour les plugins du coordinateur et les plugins de templates.
-   * Fichiers de configurations au format INI : plus rapide à analyser et plus facile à modifier qu'un fichier php+   * Fichiers de configurations au format INI : meilleur performance et plus facile à modifier qu'un fichier php
    * Des noms de répertoire, de fichier, et de classes ont été raccourcis pour plus de simplicité (*.actiongroup.php -> *.classic.php, *.dao.definition.xml -> *.dao.xml, CopixDbFactory -> jDb, CopixEventNotifier -> jEvent etc...)    * Des noms de répertoire, de fichier, et de classes ont été raccourcis pour plus de simplicité (*.actiongroup.php -> *.classic.php, *.dao.definition.xml -> *.dao.xml, CopixDbFactory -> jDb, CopixEventNotifier -> jEvent etc...)
  
Ligne 44: Ligne 44:
 D'ailleurs, si un profil désigne le driver pdo, jDb (ex CopixDbFactory) instancie une classe PDO au lieu de jDbConnection. D'ailleurs, si un profil désigne le driver pdo, jDb (ex CopixDbFactory) instancie une classe PDO au lieu de jDbConnection.
  
-À terme, jDbConnection/jDbResultSet devraient devenir obsolète, une fois que PDO sera suffisement répandu sur les serveurs.+À terme, jDbConnection/jDbResultSet devraient devenir obsolète, une fois que PDO sera suffisement stable, performant et répandu sur les serveurs.
  
 ===== Localisation ===== ===== Localisation =====

fr/jelix_vs_copix.txt · Dernière modification : 2008/12/08 22:27 de 127.0.0.1

Fils rss des changements récents dans le wiki Creative Commons License