Zend Framework 1.7Lors de la migration d'un version précédente vers Zend Framework 1.7 ou plus récent vous devriez prendre note de ce qui suit. Zend_ControllerChangement dans l'interface DispatcherLes utilisateurs ont portés l'attention sur le fait que Zend_Controller_Action_Helper_ViewRenderer utilisait une méthode de la classe abstraite du distributeur standard qui n'était pas présente dans l'interface Dispatcher.La méthode suivante a donc été ajoutée pour s'assurer que les distributeurs personnalisés continueront à fonctionner avec les implémentations embarquées :
Zend_File_TransferChangements quand vous utilisez des filtres ou des validateursCertaines remarques des utilisateurs indiquaient que les validateurs de Zend_File_Transfer ne fonctionnaient pas correctement avec Zend_Config dû au fait qu'ils n'utilisait pas de tableaux nommés. De plus, tous les filtres et validateurs de Zend_File_Transfer ont été réécrits. Même si les anciennes signatures continuent à fonctionner, elles ont été marqués comme dépréciées et émettent une notice PHP vous informant de faire le changement. La liste suivante vous montre les changements à réaliser pour une utilisation appropriée des paramètres. Filtre Rename
Example #1 Changer le filtre rename entre 1.6 et 1.7
Validateur Count
Example #2 Changer le validateur count entre 1.6 et 1.7
Validateur Extension
Example #3 Changer le validateur extension entre 1.6 et 1.7
Validateur FilesSize
De plus la signature de la méthode useByteString() a changé. Elle peut être seulement utilisée pour tester si le validateur prévoie d'utiliser les chaînes lisibles ou la valeur brute dans les messages générées. Pour paramétrer la valeur de cette option, utilisez la méthode setUseByteString(). Example #4 Changer le validateur filessize entre 1.6 et 1.7
Validateur Hash
Example #5 Changer le validateur hash entre 1.6 et 1.7
Validateur ImageSize
Example #6 Changer le validateur imagesize entre 1.6 et 1.7
Validateur Size
Example #7 Changer le validateur size entre 1.6 et 1.7
Zend_LocaleChangement dans l'utilisation de isLocale()Conformément aux standards de codage isLocale() a été changé pour retourner un booléen. Dans les versions précédentes une chaîne était retournée lors du succès. Pour la version 1.7 un mode de compatibilité a été ajouté qui vous permet d'utiliser l'ancien comportement (avec une chaîne retournée), mais ceci émet un warning pour vous informer de changer vers le nouveau comportement. Le reroutage que l'ancien comportement de isLocale() pouvait avoir à faire n'est plus nécessaire car tous les composants de l'I18N traiteront maintenant eux-mêmes le reroutage. Pour migrer vos scripts vers la nouvelle API, utilisez simplement la méthode décrite ci-dessous. Example #8 Comment changer l'appel de isLocale() de 1.6 vers 1.7 ?
Notez que vous pouvez utiliser le second paramètre pour voir si la locale est correcte sans nécessiter de reroutage.
Changement dans l'utilisation de getDefault()La signification de la méthode getDefault() a été changé étant donné que nous avons intégré une locale de framework qui peut être paramétrée avec setDefault(). Ceci ne renvoie plus la chaîne de la locale mais seulement la locale du framework. Pour migrer vos scripts vers la nouvelle API, utilisez simplement la méthode décrite ci-dessous. Example #9 Comment changer l'appel de getDefaut() de 1.6 vers 1.7 ?
Notez que le second paramètre de l'ancienne implémentation de getDefault() n'est plus disponible non plus, mais les valeurs retournées sont les mêmes.
Zend_TranslateParamétrer les languesLors de l'utilisation de la détection automatique des langues, ou du réglage manuel des langues de Zend_Translate, vous avez peut-être remarqué que de temps en temps une notice est envoyée concernant le non-ajout de traductions vides. Dans certaines versions précédentes, une exception était levée dans certains cas. Ceci intervient quand un utilisateur requête une langue non existante, vous n'avez alors aucun moyen simple de détecter ce qui ne va pas. Nous avons donc ajouté ces notices qui apparaîtront dans votre historisation et qui vous diront qu'un utilisateur a requêté une langue que vous ne supportez pas. Notez bien que votre code, même si une notice est déclenchée, fonctionnera sans problèmes. Mais quand vous utilisez votre propre gestionnaire d'erreur ou d'exception, comme xDebug, toutes les notices vous seront retournées, même si ce n'est pas votre intention initiale. Ceci est du au fait, que ces gestionnaires surchargent tous les réglages internes de PHP.
Pour vous affranchir de ces notices, vous pouvez simplement paramétrer la
nouvelle option Example #10 Paramétrer les langues sans avoir de notices
Assumons que "
Dans ce cas nous aurons une notice indiquant la non-disponibilité de la
langue "
Zend_View
Avant la version 1.7.5, l'équipe de Zend Framework a été avertie d'une faille potentielle d'inclusion de fichier local ("Local File Inclusion" (LFI)) dans la méthode Zend_View::render(). Avant 1.7.5, la méthode acceptait par défaut la possibilité de spécifier des scripts de vue comportant des indications de dossier parent (comme, "../" ou "..\"). Ceci ouvre la possibilité à une attaque LFI si des données utilisateurs non filtrées sont passées directement à la méthode render():
Zend_View émet maintenant une exception dans un tel cas. Désactiver la protection LFI de render()Comme des développeurs utilisaient de telles notations, mais qui n'étaient pas des données en provenance de l'extérieur, un drapeau spécial a été crée, il permet de désactiver la protection. Pour manipuler ce drapeau, il existe 2 moyens : le paramètre 'lfiProtectionOn' du constructeur de votre vue, ou encore la méthode setLfiProtection().
|