[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: charles
Subject: Re: [Dolibarr-dev] Fighting the db name change
Date: Sat, 24 Oct 2015 11:15:12 +0200

This mode of operation is much like m that is already in myList and
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.

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

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

-----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


Florian Henry
+33 6 03 76 48 07
Twitter : @_Open_Concept_
Google+ :

Le 23/10/2015 21:36, Frédéric FRANCE a écrit :
> Hi all
> I have posted thid PR:
> Including this in external modules may help to fight the db name 
> change(or triggers) and to reduce anxiolitic eating for developpers 
> $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

Dolibarr-dev mailing list

Aucun virus trouvé dans ce message.
Analyse effectuée par AVG -
Version: 2015.0.6173 / Base de données virale: 4450/10879 - Date: 24/10/2015

reply via email to

[Prev in Thread] Current Thread [Next in Thread]