Bonjour Thomas (et à tous)
C'est effectivement la première solution que j'avais envisagé; une
approche très orientée objet, en poussant peut-être jusqu'à gérer les
SQLquery comme des objets à part entière, comme suggéré sur ce site
(en français malheureusement )
http://www.willdurand.fr/implementation-en-php-53-des-concepts-orm-dal-dao-crud/
Il m'a semblé que gérer les requêtes de cette manière serait la
méthode la plus efficace pour implémenter les champs personnalisés et
alléger la maintenance. Néanmoins, j'ai pu voir sur le forum de
Dolibarr et sur le wiki que le projet ne tendait pas à mettre en place
un MVC2 ni une extension de framework, mais essayait de prendre le
meilleur du MVC tout en évitant une implémentation trop lourde de
l'objet qui pourrait nuire au performance.
L'utilisation de DAL me parait donc être la meilleure solution,
cependant je crois que le problème est pour l'instant plus pratique
que conceptuel, car le modèle mis en place actuellement (DAO pour
l'abstraction et l'accès SQL + main.inc & master pour le contrôle +
.php pour les actions, les templates et la vue) n'est pas mis en
pratique systématiquement (c'est compréhensible, les principaux
contributeurs mettant à jour le projet sur leur temps personnel).
Le DAO étant actuellement en charge de l'abstraction et de l'accès au
données, je pense qu'il serait judicieux de commencer par régulariser
les fichiers qui ne tiennent pas compte de son rôle, afin de ne pas
remettre en question toute la philosophie du projet tout en ouvrant
des portes pour tendre vers l'objet.
En ce qui concerne les champs personnalisés, j'avoue être un peu
coincé; je pense actuellement à le traiter comme un module à part
entière que j'implémenterais petit à petit dans les autres modules
(requête par requête -_-).
Je pense qu'il serait très intéressant qu'un ou plusieurs de
principaux contributeurs se prononcent au sujet des corrections
énoncées précédement, ce qui faciliterait à l'avenir la maintenance et
le développement.
Remerciant chacun de vous pour la lecture;
Anthony Poiret
-----Translation-----
Hi Thomas (and all)
This is actually the first solution that I considered, a very
object-oriented approach, pushing perhaps to manage SQLquery as
objects in their own right, as suggested on this site (in French
unfortunately)
http://www.willdurand.fr/implementation-en-php-53-des-concepts-orm-dal-dao-crud/
It seemed to me that running queries in this manner would be the most
effective method to implement custom fields and reduce maintenance.
Nevertheless, I could see on the forum and the wiki Dolibarr that the
project was not designed to establish a MVC2 nor an extension of any
framework, but trying to make the best of MVC while avoiding a too
heavy implementation of object that could affect the performance.
The use of DAL appears to me to be the best solution, but I think the
problem is currently more practical than conceptual, because the model
currently in place (DAO for data abstraction and access + main.inc &
master for control + .php for actions, templates and views) is not
applied consistently (it's understandable, the main contributors
updating the project on their own time ).
DAO is currently in charge of data abstraction and access, I think it
would be wise to begin by regularizing the files that do not reflect
its role, so as not to question the whole project's philosophy while
opening the doors to move gradually to object.
Regarding the custom fields, I admit being a little stuck, and I think
now to treat it as a separate module that I implement gradually in
other modules (request by request -_-).
I think it would be nice that one or more of the major contributors
decide about the corrections outlined previously, which would
facilitate future maintenance and development.
Thanking you all for reading;
Anthony Poiret
Herr Thomas Ziegler <[email protected]> a écrit :
Hello All,
this is a good idea, may be a adaption of the Drupal DAL
(http://api.drupal.org/api/drupal/includes--database--database.inc/group/database/7) is a good way to move on with
this.
Regards,
Thomas
Bonjour à tous,
c'est une bonne idée, peut-être une adaptation de la DAL
Drupal(http://api.drupal.org/api/drupal/includes--database--database.inc/group/database/7) est un bon moyen de passer à la
présente.
Cordialement,
Thomas
On May 10, 2011, at 5:24 PM, [email protected] wrote:
Rebonjour, et à nouveau mes excuses pour le double post.
Je viens de passer un bon moment à faire le tour de plusieurs
.class et .php afin de trouver des propositions alternatives à ma
précédente.
Petits résumé en trois points de mes conclusions:
1- Beaucoup d'accès sql se font hors DAO; par conséquent l'ajout
d'une possibilité globale de créer des champs pour l'utilisateur me
parait délicate, puisqu'impliquant une modification des requêtes
sql.
2- Pour pallier au pb sans essayer de corriger tous les .php, j'ai
envisagé la possibilité de considérer la génération de CustomFields
comme un module isolé, en pensant le traiter comme n'importe quel
autre module. Il aurait donc une table propre répertoriant les
champs personnalisés créés (valeur, paramètres de présentations,
names, etc), les tables auquelles il doit être associé et une class
DAO dont les CRUD comprendraient l'alter automatique des tables en
questions.
3- Du coup, il ne serait plus question dans l'immédiat de générer
des champs personnalisables dans n'importe quel contexte, mais
d'abord pour un nombre limité de module, en implémentant par la
suite petit à petit cette possibilité là ou l'intérêt s'en fait
sentir.
Je continu de chercher d'autres voies en attendant toute réflexion.
translation:
Hello again, and my apologies for the double post again.
I just spent a long time to study several. and class. php to find
alternatives to my previous proposals.
Small three-point summary of my conclusions:
1 - Many are off access sql DAO, therefore adding an overall
ability to create fields for the user seems to me difficult, as
implying a change in sql query.
2 - To overcome the problem without trying to correct all. php, I
considered the possibility of treating the generation of
CustomFields isolated as a module, thinking treat it like any other
module. It would have its own table listing the custom fields
created (value, settings presentations, names, etc.), the tables to
which it is to be associated and a DAO class with CRUD including
the automatic alter of these tables.
3 - So, it would no longer be question in the immediate to generate
custom fields in any context, but first for a limited number of
module, implementing thereafter gradually this possibility or there
interest arises.
I continue to seek alternative routes waiting for any reflection.
[email protected] a écrit :
Bonjour à tous,
J'ouvre un nouveau thread pour poursuivre sur le sujet que j'ai
lancé dans mon dernier post "patch Compta". Pour rappel:
"Autre sujet, Cyrille m'a parlé d'une tâche qui consisterait à
donner la possibilité à l'utilisateur de créer des champs
personnalisés. Si vous avez des infos ou des détails à ce sujet,
je suis preneur."
Après y avoir bien réfléchi, la solution le plus simple ne
serait-elle pas de traiter les dits champs comme des objets, et
dans ce cas, de leur faire affecter le DAO spécifique du module
où ils sont ajoutés (ou même les intégrer directement dans le
générateur de classe comme une liste de champs)?
J'imagine que l'idée n'était pas de rajouter des champs décoratifs
sans aucune relation avec la base de donnée, par conséquent
j'imagine également qu'il va bien falloir faire en sorte qu'une
telle classe puisse s'intégrer à chaque DAO...
Cependant, j'ai pu constater que bon nombre d'accès sql (notament
en travaillant sur le module tiers) n'étaient pas effectués par
le biais du DAO mais directement dans les .php. Or je suppose
(mais me trompe peut-être) que la génération de champs
personnalisée risque d'être relativement fastidieuse en cet état
de fait.
J'aimerais donc savoir si une reprise générale des .php est
envisageable pour les mettre d'équerre avec le MVC Dolibarr, afin
que les accès sql soit en pratique centralisés autour des DAO.
Commençant à comprendre la structure employée, je m'attelerai
volontier à cette tâche (sur le modèle d'un .php existant
respectant cette forme, par exemple soc.php)
Dans le cas contraire, j'accepte toute explication qui puisse me
permettre de concevoir une solution alternative pour la génération
de champs personnalisés.
En vous remerciant de votre lecture;
------Translation:------
Hello everyone,
I open a new thread to continue on the topic I started in my last post
patch Accounting. Reminder:
"Another subject, Cyril told me about a job that would give the
opportunity for users to create custom fields. If you have any info or
details about it, I'm interested."
After much thought, the simplest solution would she not treat as
objects called fields, and in this case, they do affect the
DAO-specific module where they are added (or even incorporate them
directly into the generator class as a list of fields)?
I guess the idea was not to add decorative fields without any relation
with the database, so I guess it also means that we should ensure that
such a class can be integrated each DAO ...
However, I noticed that many sql access (notably working on the third
module) were not carried through but directly in the DAO. php. But I
guess (but I may be wrong) that the generation of custom fields may be
quite tedious in this situation.
I want to know if a general resumption of. php is possible for them to
square with the MVC Dolibarr, so that access sql is centralized in
practice around the DAO. Beginning to understand the structure used, I
am working gladly to the task (on a model. php respecting the existing
form, for example soc.php)
Otherwise, I accept any explanation that would enable me to devise an
alternative solution for generating custom fields.
Thanking you for your reading;
Anthony Poiret
_______________________________________________
Dolibarr-dev mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________
Dolibarr-dev mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________
Dolibarr-dev mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
