Disparition des fichiers override depuis 1.5.4.1

[nbonniot]

Bonjour,

Je reprends un projet Prestashop avec la dernière version en place. La dernière fois que j'avais travaillé dessus, c'était avec la 1.5.3.1.

 

Je constate avec surprise que tous les override qui avaient été ajoutés (fichiers vides dans le dossier /override/) ne sont plus là et qu'il faut les saisir à la main. Outre la perte de temps (à mon avis), il y a une perte de sens certaine car un coup on travaille avec les Core, un coup avec les override.

 

Je cherche simplement à comprendre la raison de ce changement : Les changelogs que j'ai parcouru ne m'ont pas aidé, ou alors j'ai loupé l'endroit où c'était indiqué.

 

Vous avez des éléments concernant ce souci?

 

Merci d'avance !

 

Nicolas

 

[Whoami]

Bonjour,

 

Pareillement à toi j'ai remarqué que les fichiers par défaut qu'il y avait dans les débuts de la 1.5 au niveau de l'override ont été enlevés.

Cependant on est jamais censé travailler dans le Core (et ce même avant la 1.5 en fait), et l'override reste possible comme tu sembles le sous-entendre.

 

Après le pourquoi du comment, j'avoue que j'aimerai bien savoir, j'ai dû louper la révision associée à ce changement.

[math_php]

Bonjour,

 

Perso je préfère avoir un dossier avec que les overrides utilisés plutot que des tonnes de fichier vide avec dedans juste le nom de la classe.

Peut être des problèmes de performances et de clarté justifient ce changement.

 

En règle général je mets mes overrides en les couplants avec mon module.

[nbonniot]

Salut à vous 2,

Merci pour votre retour.

@math_php : ma remarque était plus d'ordre cohérence de développement objet. Par ailleurs, je ne pense pas que la perte de performance soit significative sur les classes héritées vides de /override/ surtout après les premiers passages qui génèrent le cache.

 

J'utilise Netbeans + Xdebug et ce qui me gêne le plus c'est de mélanger les ClassesCore et les Classes dans mes contrôleurs. Au-delà de la cohérence dans le nommage, il faut penser à revenir en arrière pour modifier les appels de ClassesCore si on a surchargé entre temps ladite classe. Je trouve ça personnellement dangereux sur les projet complexes et fortement customisés.

 

Avec l'ancien système on avait une cohérence d'ensemble qui rendait à mon sens le tout plus souple et plus évolutif.

 

SI je trouve la raison dans le changelog, je la publierai ici !