Ce n’est pas de mes habitudes de voir des scripts pas optimisées et ne pas le signaler!
Prenant l’exemple du script commande/card.php, il y a une 100ène d’appel de l’objet suivant : $user->rights->commande->…
Pourquoi ne pas ajouter une variable pour faciliter la vie :
Si je souhaite par exemple cloner commande en voiture, je ne dois pas l’éditer une 100ène de fois mais juste en une simple et seule modification!
Cela va améliorer les performances d’affichage des scripts en plus de la lisibilité!
L’idéal c’est de créer une interface (abstraction au vrai sens) qui gère les ACLs
J’espère que les remarques de la communauté soient prises en considération!
Merci!
autre script à optimiser : core/class/html.formfile.php
puisque c’est dans le core je ne vois pas pourquoi vous indiquer les noms de quelques modules dedans!
par exemple dans la fonction showdocuments
Pourquoi elle ne soit pas générique! à la limite ajouter une variable array à la class (FormFile) et ses fonctions set/get ou add/delete
Autre remarque, dans la même fonction des lignes de code se répète or avec deux nouveaux params/variables à la fonction/class on peut remplacer 255 ligne de code en deux lignes.
Le nom du model/chemindelaclass peut être passer en param ou même dans le tableau que j’ai suggéré ci-dessus.
De cette façon la classe devienne plus générique et vous êtes pas obliger de faire la modification pour chaque nouveau module ni de copier à chaque fois la classe…
Je n’ai pas vérifié si les corrections sont utiles mais ce n’est pas l’endroit pour les poster.
Préférez le github de Dolibarr et proposez y vos corrections et ou optimisations.
Merci d’avance
@+
Thx!
J’espère que la modification sur la class html.formfile.php sera adoptée, c’est dans l’objectif de créer des nouveaux modules plus simplement sans toucher au core! (la modification a été testé et ça fonctionne, il va falloir propager la même modification dans les autres modules avant les appels de $formfile->showdocuments. De toute façon les autres modules continuent à fonctionner aussi même sans propagation)
ma façon de raisonner : Au lieu de gérer les cas spécifiques dans les classes (ce n’est plus une classe dans ce cas), le faire dans les modules elles mêmes…
D’avance merci!
Je demande comment utiliser les objets liés dans un nouveau module sans toucher à ces deux fichiers : core/lib/files.lib.php et core/lib/functions2.lib.php
ces deux fichiers qui devrait être communs à plusieurs modules normalement on doit pas faire des dev. spécifiques pour certains modules
les fonctions : dolGetElementUrl , dol_delete_preview , dol_check_secure_access_document à revoir
Il faut penser aussi coté utilisateur qui souhaite modifier ou créer sa propre module…
@aspangaro :
Puisque vous maitrisez très bien les script je vais exposer mon cas et j’espère que vous allez réagir en fonction
J’ai cloné le module commande/expedition sous autres noms/tables (commandex/expeditionx). Cela me permet de comprendre le fonctionnement de dol et découvrir ses scripts.
Arrivant à l’affichage des expéditions/documents liés dans une fiche commande (Box objet liés en bas) j’étais obliger de modifier les fichiers suivant pour le faire fonctionner bien sur sans réinventer la roue en utilisant les mêmes scripts existantes :
Je ne pense pas que c’est beau de le faire
Voilà! Voilà! je vous laisse le soin de faire les petites modifications nécessaires pour isoler ces scripts et faire passer les modification/params spécifiques dans les modules au lieu des scripts communs et ne pas faire les modifications à chaque mise à jour.
D’avance MERCI!
