Re: [Dolibarr-dev] Fighting the db name change

[charles benke.fr]

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 : address@hidden
[mailto:address@hidden De la part de
Florian HENRY
Envoyé : samedi 24 octobre 2015 10:29
À : address@hidden
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
address@hidden
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
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev



_______________________________________________
Dolibarr-dev mailing list
address@hidden
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