[Dolibarr-dev] CustomFields Generation

[anthony . poiret]

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