Re: [Dolibarr-dev] CustomFields Generation

[anthony . poiret]

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.


address@hidden 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
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev