This mode of operation is much like m that is already in myList and customTabs Side perfs, it would be appropriate to drop the extrafields tables by adding extra-fields in tables with a different naming fields (eg "ext_name" for the fields managed extrafields) Another remark, it is already possible with "fetch_fields" mysqli function of connector to retrieve the fields of a request (function I use in mydoliboard), but this requires to function with this connector. http://php.net/manual/fr/mysqli-result.fetch-fields.php
myList is now free and open and its integration in the core would make sense but ask time to define all current listings in this format. For the screens, it might be time to put in place a real MVC formats ... The establishment of such an architecture would require a lot of work and should be considered a major release (4.xx ???) but it does bring a lot in terms of flexibility for dolibarr Go step by step is not enough, we must know where we want to go ... ______________________________________ Ce mode de fonctionnement ressemble beaucoup à m ce qui est déjà fait dans myList et customTabs Coté perfs, Il serait pertinent d'abandonner les tables extrafields par l'ajout dans les tables de base de dolibarr avec un nommage différent des champs (ex "ext_name" pour les champs géré en extrafields) Autre remarque, il est déjà possible avec la fonction fetch_fields du connecteur mysqli de récupérer les champs d'une requete (fonction que j'utilise dans mydoliboard), mais cela oblige à fonctionner qu'avec ce connecteur. myList est à présent libre et gratuit et son intégration dans le core aurait du sens mais demanderai du temps pour définir la totalité des listes actuels dans ce format. Pour ce qui est des écrans, il serait peut etre temps de mettre en place un vrai format MVC ... La mise en place d'une tel architecture nécessiterait beaucoup de travail et devrait être considéré comme une version majeur (4.x.x ???) mais effectivement elle apporterai beaucoup en terme de flexibilité à dolibarr Aller étape par étape ne suffit pas, il faut savoir où l'on souhaite aller... -----Message d'origine----- De : [email protected] [mailto:[email protected]] De la part de Florian HENRY Envoyé : samedi 24 octobre 2015 10:29 À : [email protected] Objet : Re: [Dolibarr-dev] Fighting the db name change Hello all, It is a good point to introduce a dictionary structure into Dolibarr, but I feel a different and more global way. I will prefer get this informations from tables rather than in a PHP file. Table "Object" with field "Class name","Class path", .... a table "Object_field" with field "name", "type","table_FK", "etc...", " as it is done more or less into object_extrafields table. An auto-descritif table models will be a very nice improvement and open gate to lot's of time reduction in dev. Why store this into database rather than PHP file ? Because tomorrow Python application can read object structure from DB, not from PHP file. Anyway, it is a good at least a good start, and as Laurent says "step by step". Regards Florian Henry +33 6 03 76 48 07 [email protected] http://www.open-concept.pro Twitter : @_Open_Concept_ Google+ : https://www.google.com/+Open-conceptPro Le 23/10/2015 21:36, Frédéric FRANCE a écrit : > Hi all > I have posted thid PR: https://github.com/Dolibarr/dolibarr/pull/3796 > Including this in external modules may help to fight the db name > change(or triggers) and to reduce anxiolitic eating for developpers > you can do $sql = "SELECT * FROM ".MAIN_DB_PREFIX.TABLE_THIRDPARTY; > $sql .= " WHERE ".THIRDPARTY_FK_SOC." = ".$object->id; in place of > knowing the right name of past and future dolibarr version > > Feel free to comment and populate the file if you think it's right No > need to check version if the file is correctly maintained > > With best regards > Frederic FRANCE > > _______________________________________________ > 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 ----- Aucun virus trouvé dans ce message. Analyse effectuée par AVG - www.avg.fr Version: 2015.0.6173 / Base de données virale: 4450/10879 - Date: 24/10/2015 _______________________________________________ Dolibarr-dev mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
