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
