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