| Les deux révisions précédentesRévision précédente | Prochaine révisionLes deux révisions suivantes |
| jelix_vs_copix [2006/11/08 11:02] – (old revision restored) 127.0.0.1 | jelix_vs_copix [2007/01/06 00:23] – laurent |
|---|
| * Il n'y a plus de fichier *.desc.php. le "mapping" des actions se fait directement sur les actiongroups. | * Il n'y a plus de fichier *.desc.php. le "mapping" des actions se fait directement sur les actiongroups. |
| * les actiongroups s'appellent maintenant des contrôleurs. La classe CopixActionGroup fait place à jController | * les actiongroups s'appellent maintenant des contrôleurs. La classe CopixActionGroup fait place à jController |
| * 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 contrôle 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 apparaitre (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. | * les plugins de templates sont dédiés à un format de sortie spécifique. |
| * 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) | * Les sélecteurs : la syntaxe a changé "type:module~ressource" ou "module~ressource". De plus la gestion des selecteurs a été optimisée. |
| * 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" |
| 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 stable, performant et répandu sur les serveurs. | À terme, jDbConnection/jDbResultSet devraient devenir obsolète, une fois que PDO sera suffisamment stable, performant et répandu sur les serveurs. |
| |
| ===== Localisation ===== | ===== Localisation ===== |
