Guide de Migration 2.0¶

Noms des Fichiers¶

Tous les fichiers contenant les classes doivent être nommés selon la classe qu’il contiennent. Aucun fichier ne doit contenir plus d’une classe. Donc, plus de minuscules ou de soulignements dans les noms de fichier. Voici quelques exemples:

• mes_trucs_controller.php devient MesTrucsController.php

• form.php (un Helper) devient FormHelper.php

• session.php (un Component) devient SessionComponent.php

Cela rend le nommage des fichiers beaucoup plus clair et cohérent à travers les applications, et aussi évite quelques cas où le chargement des fichiers aurait pu été géné dans le passé et aurait pu entrainé un chargement non souhaité de fichiers.

Les Noms des Dossiers¶

La plupart des dossiers devront être en CamelCase, spécialement ceux contenant des classes. En songeant aux espaces de noms, chaque dossier représente un niveau dans la hiérachie des espaces de noms, les dossiers qui ne contiennent pas de classes, ou ne constituent pas un espace de noms sur eux-mêmes, devraient être en LowerCase.

Dossiers en CamelCase:

• Config

• Console

• Controller

• Controller/Component

• Lib

• Locale

• Model

• Model/Behavior

• Plugin

• Test

• Vendor

• View

• View/Helper

Dossiers en LowerCase:

• tmp

• webroot

Constantes Retirées¶

Un nombre de constantes ont été retirées, puisqu’elles n’ataient plus exactes ou bien étaient dupliquées.

• APP_PATH

• BEHAVIORS

• COMPONENTS

• CONFIGS

• CONSOLE_LIBS

• CONTROLLERS

• CONTROLLER_TESTS

• ELEMENTS

• HELPERS

• HELPER_TESTS

• LAYOUTS

• LIB_TESTS

• LIBS

• MODELS

• MODEL_TESTS

• SCRIPTS

• VIEWS

Callbacks dépréciés supprimés¶

Tous les callbacks dépréciés dans Component ont été transférés à ComponentCollection. A la place, vous devriez utiliser la méthode trigger() pour intéragir avec les callbacks. Si vous avez besoin de déclencher un callback, vous pouvez le faire en appelant:

$this->Components->trigger('someCallback', array(&$this));

Changement dans la désactivation des components¶

Dans le passé, vous étiez capable de désactiver les components via $this->Auth->enabled = false; par exemple. Dans CakePHP 2.0 vous devriez utiliser la méthode de désactivation des ComponentCollection’s, $this->Components->disable(“Auth”);. Utiliser les propriétés actives ne va pas fonctionner.

AclComponent¶

• Les implémentations AclComponent sont maintenant requises pour implémenter AclInterface.

• AclComponent::adapter() a été ajouté pour permettre l’éxecution de la modification de l’utilisation de l’implémentation du component ACL.

• AclComponent::grant() a été déprécié, il sera supprimé dans une version future. Utilisez AclComponent::allow() à la place.

• AclComponent::revoke() a été déprécié, il sera supprimé dans une version future. Utilisez AclComponent::deny() à la place.

RequestHandlerComponent¶

Beaucoup de méthodes de RequestHandlerComponent sont justes des proxies pour les méthodes de CakeRequest. Le méthodes suivantes ont été dépréciées et seront retirées dans les versions futures:

• isSsl()

• isAjax()

• isPost()

• isPut()

• isFlash()

• isDelete()

• getReferer()

• getClientIp()

• accepts(), prefers(), requestedWith() Tous sont maintenant gérés

  dans les types de contenu. Ils ne fonctionnent plus avec les mime-types. Vous pouvez utiliser RequestHandler::setContent() pour créer des nouveaux types de contenu.

• RequestHandler::setContent() n’accepte plus de tableau en tant

  qu’argument unique, vous devez fournir les deux arguments.

SecurityComponent¶

SecurityComponent ne gère plus l’Authentification Basic et Sommaire (Digest). Elles sont toutes deux gérées par le nouveau AuthComponent. Les méthodes suivantes ont été retirées de SecurityComponent:

• requireLogin()

• generateDigestResponseHash()

• loginCredentials()

• loginRequest()

• parseDigestAuthData()

De plus les propriétés suivantes ont été retirées:

• $loginUsers

• $requireLogin

Le déplacement des fonctionalités verss Authcomponent a été faite pour fournir un endroit unique pour tous les types d’authentification et pour rationaliser les rôles de chaque component.

AuthComponent¶

AuthComponent a été entièrement refait dans 2.0, ça a été fait pour réduire les confusions et frustrations des développeurs. De plus, AuthComponent a été construit plus flexible et extensible. Vous pouvez trouver plus d’informations dans le guide Authentification.

EmailComponent¶

EmailComponent a été déprecié et a été crée une nouvelle classe de librairie pour envoyer les emails. Voir les changements pour Email CakeEmail pour plus de détails.

SessionComponent¶

SessionComponent a perdu les méthodes suivantes.

• activate()

• active()

• __start()

App¶

L’API pour App::build() a changé pour App::build($paths, $mode). Elle vous autorise maintenant à soit ajouter, soit faire précéder ou bien réinitialiser / remplacer les chemins existants. Le paramètre $mode peut prendre n’importe lesquelles des 3 valeurs suivantes: App::APPEND, App::PREPEND, App::RESET. Le behavior par défaut de la fonction reste le même (ex. Faire précéder des nouveaux chemins par une liste existante).

App::uses('AuthComponent', 'Controller/Component');

App::import('Controller', 'Pages');
// devient
App::uses('PagesController', 'Controller');

App::import('Component', 'Auth');
// devient
App::uses('AuthComponent', 'Controller/Component');

App::import('View', 'Media');
// devient
App::uses('MediaView', 'View');

App::import('Core', 'Xml');
// devient
App::uses('Xml', 'Utility');

App::import('Datasource', 'MongoDb.MongoDbSource')
// devient
App::uses('MongoDbSource', 'MongoDb.Model/Datasource')

App::import('Core', 'CakeRoute');
// devient
App::uses('CakeRoute', 'Routing/Route');

App::import('Core', 'Sanitize');
// devient
App::uses('Sanitize', 'Utility');

App::import('Core', 'HttpSocket');
// devient
App::uses('HttpSocket', 'Network/Http');

App::build(array('controllers' => array('/chemin/complet/vers/controllers')))
//devient
App::build(array('Controller' => array('/chemin/complet/vers/controllers')))

App::build(array('helpers' => array('/chemin/complet/vers/controllers')))
//devient
App::build(array('View/Helper' => array('/chemin/complet/vers/Vues/Helpers')))

CakeLog¶

• La connexion aux flux a maintenant besoin de mettre en œuvre: php: class: CakeLogInterface. Des exceptions seront soulevées si un enregistreur n’est pas configuré.

Cache¶

• Cache est maintenant une classe statique, elle n’a plus de méthode getInstance().

• CacheEngine est maintenant une classe abstraite. Vous ne pouvez plus directement créer d’instances de celle-ci.

• Les implémentations de CacheEngine doivent étendre CacheEngine, des exceptions seront soulevées si une classe de configuration ne l’est pas.

• FileCache nécessite maintenant l’ajout de barres obliques au chemin de configuration lorsque vous modifiez une configuration du cache.

• Cache ne retient plus le nom du dernier moteur de cache configuré. Cela signifie que les opérations que vous souhaitez produire sur un moteur spécifique doivent avoir le paramètre $config égale au nom de config que vous souhaitez.

Cache::config('quelquechose');
Cache::write('key', $valeur);

// deviendrait
Cache::write('key', $valeur, 'quelquechose');

Router¶

• Vous ne pouvez plus modifier les paramètres de configuration avec Router::setRequestInfo(). Vous devriez utiliser Router::connectNamed() pour configurer la façon dont les paramètres nommés sont gérés.

• Le Router n’a plus de méthode getInstance(). C’est une classe statique, appelle ses méthodes et propriétés de façon statique.

• Router::getNamedExpressions() est deprécié. Utilisez les nouvelles constantes du routeur. Router::ACTION, Router::YEAR, Router::MONTH, Router::DAY, Router::ID, et Router::UUID à la place.

• Router::defaults() a été retiré. Supprimer l’inclusion de fichier des routes du coeur de votre fichier routes.php de vos applications pour désactiver le routing par défaut. Inversement, si vous voulez le routing par défaut, vous devrez ajouter une inclusion dans votre fichier de routes Cake/Config/routes.php.

• Quand vous utilisez Router::parseExtensions() le paramètre d’extension n’est plus sous $this->params['url']['ext']. A la place, il est disponible avec $this->request->params['ext'].

• Les routes des plugins par défaut ont changé. Les routes courtes de Plugin ne sont plus construites que dans les actions index. Précédemment /users` et /users/add mappaient le UsersController dans le plugin Users. Dans 2.0, seule l’action index est donné par une route courte. Si vous souhaitez continuer à utiliser les routes courtes, vous pouvez ajouter une route comme:

  Router::connect('/users/:action', array('controller' => 'users', 'plugin' => 'users'));
  

  Pour votre fichier de routes pour chaque plugin, vous avez besoin de routes courtes actives.

Votre fichier app/Config/routes.php doit être mis à jour en ajoutant cette ligne en bas du fichier:

require CAKE . 'Config' . DS . 'routes.php';

Cela est nécessaire afin de générer les routes par défaut pour votre application. Si vous ne souhaitez pas avoir de telles routes, ou si vous voulez implémenter votre propre standard, vous pouvez inclure votre propre fichier avec vos propres règles de routeur.

Dispatcher¶

• Le Dispatcher a été déplacé dans cake/libs, vous devrez mettre à jour votre fichier app/webroot/index.php.

• Le Dispatcher::dispatch() prend maintenant deux paramètres. Les objets request et response. Ceux-ci devraient être des instances de CakeRequest & CakeResponse ou une sous-classe de ceux-ci.

• Dispatcher::parseParams() n’accepte que l’objet CakeRequest.

• Dispatcher::baseUrl() a été retiré.

• Dispatcher::getUrl() a été retiré.

• Dispatcher::uri() a été retiré.

• Dispatcher::$here a été retiré.

Configure¶

• Configure::read() avec aucun paramètre ne retourne plus la valeur de “debug”, à la place elle retourne toutes les valeurs dans Configure. Utilisez Configure::read('debug'); si vous voulez la valeur de debug.

• Configure::load() requiert maintenant un ConfigReader pour être configuré. Lisez Chargement des fichiers de configuration pour plus d’informations.

• Configure::store() écrit maintenant les valeurs à une configuration du Cache donnée. Lisez Chargement des fichiers de configuration pour plus d’informations.

Scaffold¶

• Les vues Scaffold “edit” devront être renommées par “form”. Cela a été fait pour rendre les templates scaffold et bake cohérents.

  • views/scaffolds/edit.ctp -> View/Scaffolds/form.ctp

  • views/posts/scaffold.edit.ctp -> View/Posts/scaffold.form.ctp

Xml¶

• La classe Xml a été complètement reconstruite. Maintenant cette classe ne manipule plus de données, et elle est un enrouleur (wrapper) pour les SimpleXMLElement. Vous pouvez utiliser les méthodes suivantes:

  • Xml::build(): Méthode statique dans laquelle vous pouvez passer une chaîne de caractère xml, un tableau, un chemin vers un fichier ou une url. Le résultat va être une instance SimpleXMLElement ou une exception va être envoyée en cas d’erreurs.

  • Xml::fromArray(): Méthode statique qui retourne un SimpleXMLElement à partir d’un tableau.

  • Xml::toArray(): Méthode statique qui retourne un tableau à partir de SimpleXMLElement.

Vous devez utiliser la documentation Xml pour plus d’informations sur les changements faits sur la classe Xml.

Inflector¶

• L’Inflecteur n’a plus de méthode getInstance().

• Inflector::slug() ne supporte plus l’argument $map. Utilisez Inflector::rules() pour définir les règles de translitération.

CakeSession¶

CakeSession est maintenant une classe complètement statique, les deux SessionHelper et SessionComponent sont des wrappers et du sucre pour celui-ci. Il peut facilement être utilisé dans les models ou dans d’autres contextes. Toutes ses méthodes sont appelées de façon statique.

La configuration de Session a aussi changé Voir la section session pour plus d’informations

HttpSocket¶

• HttpSocket ne change pas les clés d’en-tête. Suivant les autres endroits dans le coeur, le HttpSocket ne change pas les headers. RFC 2616 dit que les en-têtes sont insensibles à la casse, et HttpSocket préserve les valeurs envois de l’hôte distant.

• HttpSocket retourne maintenant les réponses en objets. Au lieu des tableaux, HttpSocket retourne les instances de HttpResponse. Voir la documentation de HttpSocket pour plus d’informations.

• Les cookies sont stockés en interne par l’hôte, pas par instance. Cela signifie que, si vous faîtes deux requêtes à différents serveurs, les cookies du domaine1 ne seront pas envoyés au domaine2. Cela a été fait pour éviter d’éventuels problèmes de sécurité.

Changement du constructeur¶

Afin de prendre en considération le fait que View a été retiré de la ClassRegistry, la signature du Helper::__construct() a été changée. Vous devez mettre à jour toutes les sous-classes pour utiliser ce qui suit:

public function __construct(View $View, $settings = array())

Quand vous écrasez le constructeur, vous devez toujours aussi appeler parent::__construct. Helper::__construct stocke l’instance de vue dans $this->_View pour une référence future. Les configurations ne sont pas gérées par le constructeur parent.

HelperCollection ajouté¶

Après un examen des responsabilités de chaque classe impliquée dans la couche Vue, il nous est clairement apparu que la Vue gérait bien plus qu’une unique tâche. La responsabilité de créer les helpers n’est pas centrale dans ce que la Vue fait, et a été déplacée dans le HelperCollection. HelperCollection est responsable du chargement et de la construction des helpers, ainsi que de déclencher les callbacks sur les helpers. Par défaut, la Vue crée un HelperCollection dans son constructeur, et l’utilise pour des opérations ultérieures. L’HelperCollection pour une vue peut être trouvé dans $this->Helpers.

Les motivations pour la reconstruction de cette fonctionnalité vient de quelques soucis.

• La Vue qui était enregistrée dans ClassRegistry pouvait causer des problèmes empoisonnés d’enregistrement quand requestAction ou l’EmailComponent étaient utilisés.

• La Vue accessible comme un symbole global entraînait des abus.

• Les Helpers n’étaient pas contenus eux-mêmes. Après avoir construit un helper, vous deviez construire manuellement plusieurs autres objets afin d’obtenir un objet fonctionnant.

Vous pouvez en lire plus sur HelperCollection dans la documentation Collections.

Propriétés dépréciées¶

Les propriétés suivantes sur les helpers sont depréciées, vous devez utiliser les propriétés de l’objet request ou les méthodes de l’Helper plutôt que accéder directement à ces propriétés puisqu’elles seront supprimées dans une version future.

• Helper::$webroot est depréciée, utilisez la propriété webroot de l’objet request.

• Helper::$base est depréciée, utilisez la propriété base de l’objet request.

• Helper::$here est depréciée, utilisez la propriété here de l’objet request.

• Helper::$data est depréciée, utilisez la propriété data de l’objet request.

• Helper::$params est depréciée, utilisez $this->request à la place.

XmlHelper, AjaxHelper et JavascriptHelper retirés¶

Les Helpers AjaxHelper et JavascriptHelper ont été retirés puisqu’ils étaient dépréciés dans la version 1.3. Le Helper XmlHelper a été retiré, puisqu’il était obsolète et superflu avec les améliorations de Xml. La classe Xml doit être utilisée pour remplacer les utilisations anciennes de XmlHelper.

Les Helpers AjaxHelper et JavascriptHelper sont remplacés par les Helpers JsHelper et HtmlHelper.

JsHelper¶

• JsBaseEngineHelper est maintenant abstrait, vous devrez implémenter

  toutes les méthodes qui généraient avant des erreurs.

PaginatorHelper¶

• PaginatorHelper::sort() prend maintenant les arguments title et key dans

  l’ordre inversé. $key sera maintenant toujours le premier. Cela a été fait pour prévenir les besoins d’échange des arguments lors de l’ajout d’un second argument.

• PaginatorHelper avait un nombre de changements pour les paramètres de pagination utilisé en interne. Le key par défaut a été retiré.

• PaginatorHelper supporte maintenant la génération des liens avec les paramètres de pagination dans querystring.

Il y a eu quelques améliorations dans pagination en général. Pour plus d’informations sur cela, vous devriez lire la page des nouvelles fonctionnalités de pagination.

FormHelper¶

CacheHelper¶

Le CacheHelper a été complètement découplé de la Vue, et des utilisations des callbacks du Helper pour générer des caches. Vous devez retenir de placer CacheHelper après les autres helpers qui modifient le contenu dans les callbacks afterRender et afterLayout. Si vous ne le faîtes pas, certains changements ne feront pas parti du contenu récupéré.

CacheHelper n’utilise également plus <cake:nocache> pour indiquer les régions non mises en cache. A la place, il utilise les commentaires spéciaux HTML/XML. <!--nocache--> et <!--/nocache-->. Cela aide CacheHelper à générer des balises valides et continue à effectuer les mêmes fonctions qu’avant. Vous pouvez en lire plus sur CacheHelper et les changements de Vue.

Les formats des attributs d’Helper plus flexibles¶

La classe Helper a 3 attributs protégés:

• Helper::_minimizedAttributes: tableau avec des attributs minimums (ex: array('checked', 'selected', ...));

• Helper::_attributeFormat: comment les attributs vont être générés (ex: %s="%s");

• Helper::_minimizedAttributeFormat: comment les attributs minimums vont être générés: (ie %s="%s")

Par défaut, les valeurs utilisées dans CakePHP 1.3 n’ont pas été changées. Mais vous pouvez maintenant utiliser les attributs boléens de HTML, comme <input type="checkbox" checked />. Pour cela, changez juste $_minimizedAttributeFormat dans votre AppHelper en %s.

Pour utiliser avec les helpers Html/Form et les autres, vous pouvez écrire:

$this->Form->checkbox('field', array('checked' => true, 'value' => 'une_valeur'));

Une autre aptitude est que les attributs minimums peuvent être passés en item et pas en clé. Par exemple:

$this->Form->checkbox('field', array('checked', 'value' => 'une_valeur'));

Notez que checked a une clé numérique.

Pagination¶

La Pagination était traditionnellement une unique méthode dans le Controller, cela créait pourtant un nombre de problèmes. La Pagination était difficile à étendre, remplacer et modifier. Dans 2.0, la pagination a été extraite dans un component. Controller::paginate() existe toujours, et sert en tant que méthode commode pour le chargement et en utilisant le PaginatorComponent.

Pour plus d’informations sur les nouvelles fonctionnalités offertes par la pagination dans 2.0, voir la documentation Pagination.

La Vue n’est plus enregistrée dans ClassRegistry¶

La vue enregistrée dans ClassRegistry entraînait des abus et créait effectivement un symbole global. Dans 2.0 chaque Helper reçoit l’instance Vue courante dans son constructeur. Cela autorise l’accès aux vues pour les helpers de la même façon que dans le passé, sans créer de symboles globaux. Vous pouvez accéder à l’instance de vue dans $this->_View dans n’importe quel helper.

Propriétés dépréciées¶

• View::$webroot est deprécié, utilisez la propriété webroot de l’objet request.

• View::$base est deprécié, utilisez la propriété base de l’objet request.

• View::$here est deprécié, utilisez la propriété here de l’objet request.

• View::$data est deprécié, utilisez la propriété data de l’objet request.

• View::$params est deprécié, utilisez $this->request à la place.

• View::$loaded a été retiré. Utilisez HelperCollection pour accéder aux helpers chargés.

• View::$model a été retiré. Ce behavior est maintenant dans Helper

• View::$modelId a été retiré. Ce behavior est maintenant dans Helper

• View::$association a été retiré. Ce behavior est maintenant dans Helper

• View::$fieldSuffix a été retiré. Ce behavior est maintenant dans Helper

• View::entity() a été retiré. Ce behavior est maintenant dans Helper

• View::_loadHelpers() a été retiré, utilisez View::loadHelpers() à la place.

• La façon dont View::element() utilise le cache a changé, voir en-dessous pour plus d’informations.

• Les callbacks de Vue ont été transférés, voir en-dessous pour plus d’informations.

• L’API pour View::element() a changé. Lire ici pour plus d’informations.

Les propriétés depréciées de Vue seront accessibles à travers une méthode __get(). Cette méthode va être retirée dans les versions futures, ainsi il est recommandé que vous mettiez à jour votre application.

Méthodes retirées¶

• View::_triggerHelpers() Utilisez $this->Helpers->trigger() à la place.

• View::_loadHelpers() Utilisez $this->loadHelpers() à la place. Les Helpers chargent maintenant facilement leurs propres helpers.

Méthodes ajoutées¶

• View::loadHelper($name, $settings = array()); Charge un unique helper.

• View::loadHelpers() charge tous les helpers indiqués dans View::$helpers.

View->Helpers¶

Par défaut, les objets Vue contiennent un HelperCollection dans $this->Helpers.

Thèmes¶

Pour utiliser les thèmes dans vos Controllers, vous n’avez plus à mettre var $view = 'Theme';. Utilisez public $viewClass = 'Theme'; à la place.

Changements de positionnement des callbacks¶

beforeLayout utilisé pour se déclencher après scripts_for_layout et content_for_layout a été préparé. Dans 2.0, beforeLayout est tiré avant que toute variable spéciale soit préparée, vous autorisant à les manipuler avant qu’elles soient passées au layout. La même chose a été faite pour beforeRender. Il est maintenant tiré bien avant que toute variable soit manipulée. En plus de ces changements, les callbacks des helpers reçoivent toujours le nom du fichier qui est sur le point d’être rendu. Ceci, combiné avec le fait que les helpers soient capables d’accéder à la vue à travers $this->_View et la vue courante du contenu à travers $this->_View->output vous donne plus de puissance qu’avant.

La signature du callback Helper change¶

Les callbacks de Helper récupèrent maintenant toujours un argument passé à l’intérieur. Pour BeforeRender et afterRender, c’est le fichier vue qui est rendu. Pour beforeLayout et afterLayout, c’est le fichier layout qui est rendu. Vos signatures de fonction des helpers doivent ressembler à cela:

public function beforeRender($viewFile) {

}

public function afterRender($viewFile) {

}

public function beforeLayout($layoutFile) {

}

public function afterLayout($layoutFile) {

}

L’élément attrapé, et les callbacks de vue ont été changés dans 2.0 pour vous aider à vous fournir plus de flexibilité et de cohérence. Lire plus sur les changements.

CacheHelper decouplé¶

Dans les versions precédentes, il y avait un couplage étroit entre CacheHelper et View. Dans 2.0 ce couplage a été retiré et CacheHelper utilise juste les callbacks comme les autres helpers pour générer la page complète mise en cache.

CacheHelper <cake:nocache> tags changés¶

Dans les versions précédentes, CacheHelper utilise un tag spécial <cake:nocache> comme marqueur pour la sortie qui ne devrait pas faire partie de la page entièrement mise en cache. Ces tags ne faisaient parti d’aucun schéma XML, et il n’était pas possible de valider dans les documents HTML et XML. Dans 2.0, ces tags ont été remplacés avec des commentaires HTML/XML:

<cake:nocache> devient <!--nocache-->
</cake:nocache> devient <!--/nocache-->

Le code interne pour la page vue complète mise en cache a aussi été changé, alors assurez vous de nettoyer le cache de la vue quand vous mettez à jour.

Changements de MediaView¶

MediaView::render() force maintenant le téléchargement de types de fichiers inconnus à la place de juste retourner false. Si vous le voulez, vous pouvez fournir un fichier de téléchargement alternatif, vous spécifiez le nom complet incluant l’extension en utilisant la clé “name” dans le paramètre tableau passé à la fonction.

Plus de tests groupés¶

PHPUnit ne fait pas la différence entre les cas de tests groupés et les cas de tests uniques. A cause de cela, les options des tests groupés, et le support pour les tests groupés à l’ancienne ont été retirés. Il est recommandé que les TestGroupés soient portés vers les sous-classes de PHPUnit_Framework_Testsuite. Vous pouvez trouver plusieurs exemples de ceci dans la suite de test de CakePHP. Les méthodes liées aux tests groupés dans TestManager ont aussi été retirées.

Shell Testsuite¶

Le shell Testsuite a eu ses invocations simplifiées et étendues. Vous n’avez plus besoin de faire la différenciation entre case et group. On suppose que tous les tests sont des cas. Dans le passé, vous vous auriez fait cake testsuite app case models/post, vous pouvez maintenant faire cake testsuite app Model/Post.

Le shell Testsuite a été reconstruit pour utiliser l’outils CLI de PHPUnit. Cela supporte maintenant toutes les options de ligne de commande supportées par PHPUnit. cake testsuite help vous montrera une liste de toutes les modifications possibles.

Objets Database (Base de Données)¶

CakePHP 2.0 introduit quelques changements dans les objets Database qui ne devraient pas affecter grandement la compatibilité rétro-active. Le plus grand changement est l’adoption de PDO pour la gestion des connexions aux bases de données. Si vous utilisez une installation vanilla de PHP 5, vous aurez déjà les extensions nécessaires installées, mais il se peut que vous dussiez activer les extensions individuelles pour chaque driver que vous souhaitez utiliser.

Utiliser PDO à travers toutes les BDD nous permet d’homogénéiser le code pour chacune et fournit un comportement plus fiable et prévisible pour tous les drivers. Il nous a également permis d’écrire des tests plus précis et portables pour le code de la base de données liée.

La première chose qui va probablement manquer aux users, est les statistiques « lignes affectées » et « total de lignes », comme elles ne sont pas reportées à cause d’un design de PDO plus performant et paresseux, il y a des façons de régler ce problème, mais qui sont très spécifiques à chaque base de données. Ces statistiques ne sont pas parties cependant, mais pourraient manquer ou même être inexactes pour certains drivers.

Une fonctionnalité sympa ajoutée après l’adoption de PDO est la possibilité d’utiliser des requêtes préparées avec des placeholders de requêtes utilisant le driver natif si il est disponible.

BehaviorCollection¶

• BehaviorCollection ne met plus en minuscule strtolower() les mappedMethods. Les mappedMethods des Behaviors sont maintenant sensible à la casse.

AclBehavior et TreeBehavior¶

• Ne supporte plus les chaînes de caractère pour la configuration. Exemple:

  public $actsAs = array(
      'Acl' => 'Controlled',
      'Tree' => 'nested'
  );
  

  devient:

  public $actsAs = array(
      'Acl' => array('type' => 'Controlled'),
      'Tree' => array('type' => 'nested')
  );
  

Plugin App Controller et Plugin App Model¶

Les plugins AppController et AppModel ne sont plus directement localisés dans le dossier plugin. Ils sont maintenant placés dans les dossiers des plugins des Controllers et des Models comme ceci:

/app
    /Plugin
        /Comment
            /Controller
                CommentAppController.php
            /Model
                CommentAppModel.php

Changements Rétro-incompatibles de l’API du Shell¶

• Shell n’a plus d’instance AppModel. Cette instance AppModel n’était pas correctement construite et était problématique.

• Shell::_loadDbConfig() a été retiré. Il n’était pas assez générique pour rester dans le Shell. Vous pouvez utiliser DbConfigTask si vous avez besoin de demander à l’utilisateur de créer une config db.

• Shells n’utilise plus $this->Dispatcher pour accéder à stdin, stdout, et stderr. Ils ont maintenant les objets ConsoleOutput et ConsoleInput pour gérer cela.

• Shells chargent les tâches facilement, et utilisent TaskCollection pour fournir une interface similaire à celle utilisée pour les Helpers, Components, et Behaviors pour le chargement à la volée des tâches.

• Shell::$shell a été retiré.

• Shell::_checkArgs() a été retiré. Configurer un ConsoleOptionParser

• Shells n’ont plus d’accès direct à ShellDispatcher. Vous devez utiliser les objets ConsoleInput et ConsoleOutput à la place. Si vous avez besoin de dispatcher d’autres shells, regardez la section sur “invoquer d’autres shells à partir de votre shell”.

Changements Rétro-incompatibles de l’API du ShellDispatcher¶

• ShellDispatcher n’a plus de fichiers de gestion stdout, stdin, stderr.

• ShellDispatcher::$shell a été retirée.

• ShellDispatcher::$shellClass a été retirée.

• ShellDispatcher::$shellName a été retirée.

• ShellDispatcher::$shellCommand a été retirée.

• ShellDispatcher::$shellPaths a été retirée, utilisez App::path('shells'); à la place.

• ShellDispatcher n’utilise plus “help” comme méthode magique qui a un statut spécial. A la place, utilisez les options --help/-h, et un parseur d’option.

Changements Rétro-incompatibles du Shell¶

• Bake’s ControllerTask ne prend plus public et admin comme arguments passés. Ce sont maintenant des options, indiquées par --admin et --public.

Il est recommandé que vous utilisiez le help sur les shells que vous utilisiez pour voir si tous les paramètres ont changé. il est aussi recommandé que vous lisiez les nouvelles fonctionnalités de la console, pour plus d’informations sur les nouvelles APIs qui sont disponibles.