dolibarr-dev
[Top][All Lists]
Advanced

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

Re: [Dolibarr-dev] Ajout de détails sur les articles - Notion d'attribu


From: Cyrille de Lambert
Subject: Re: [Dolibarr-dev] Ajout de détails sur les articles - Notion d'attributs
Date: Sun, 19 Jun 2011 09:46:35 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; fr-FR; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10

Il faut mettre en place un système permettant de définir :
  • Les groupes d'attributs (table group_extrafield). Un enregistrement appartenant à un groupe d'attributs verra les champs de ce groupe apparaître.
  • Système de dictionnaire pour la valeur de champ (le même que pour monsieur/madame actuellement)
  • Les attributs (table_extrafield) :
    • Nom (pouvant être traduit via le système actuel)
    • Type (sélection, texte, etc)
    • Longueur
    • Position dans la vue ou le formulaire
C'est peut-être un peu prématuré de prévoir un système d'interaction entre les champs (type pays/départements), car ça me parait complexe dans un premier temps. Mais à voir.
Pour le stockage, le système de Laurent est de ce qui a de plus performant pour l'application dans le temps.
Des systèmes à la Magento étant incapable de monter en charge. D'ailleurs, ce système disparait même au sein de Magento.

Par contre, je me demandais sur le fait de créer des tables à la volée, une pour chaque groupe, n'était pas envisageable ?
Exemple : societe_extrafields_group

Toujours avec le lien 1-1

Dans tous les cas, il ne fait pas permettre la destruction des attributs et tables (si c'est les cas) via l'application.
Seul l'affichage pouvant-être occulté. L'opération de suppression étant une opération de maintenance SQL.

Cyrille


Le 19/06/2011 02:05, Régis Houssin a écrit :
"Ajout de détails sur les articles - Notion d'attributs"

le titre du mail correspond aux déclinaisons de produits non ?

;-))

en ce qui concerne les "champs personnalisés" :

une table du style "societe_extrafields" que tu viens de créer avec des
champs créés en fonctions des besoins me semble restreint !

admettons... on défini des fonctions spécifiques par type de champ et on
crée un champ dans la table pour définir que telle fiche d'un élément a
tel champ perso (function), il reste à définir les composants de ce
champs supplémentaires :

- longueur du champs
- valeurs du champ (liste déroulante, case à cocher, ...)
- possible interaction avec un autre champ si on sélectionne une valeur
d'un champ
- etc...

où on stock tout ça ?


Le 19/06/11 01:45, Laurent Destailleur (eldy) a écrit :
Le 18/06/2011 10:36, Régis Houssin a écrit :
ca va être ingérable,
imagine un catalogue avec 10000 produit composé 50 familles de produits
dont chaque famille à des types d'attributs différents, nous allons
avoir une ribambelle de champs inutiles en fonction des familles dans
les tables !!

On peut imaginer la meme chose dans plein de tables différentes mais
c'est encore tout aussi (en fait plus) dur à gérer.


10 000 produits de 50 familles avec 5 attribtus par famille, soit 25
millions d'info à renseigner, c'est loin de représenter la majorité des
TPE qui utilisent Dolibarr. Donc pour ce besoins, un modules externe qui
amènerait sa propre gestion avec ses tables de familles, tables
d'attributs, tables de liens familles-attributs, etc, sera de rigueur.
Amoins que tu ne fasse allusion aux "déclinaisons" mais la c'est une
tout autre fonction que les attributs personnalisés et qui est propre
aux produits.
Les attributs personnalisés seront une mécanisme générique pour tout
entité dolibarr.
Cordialement,
_______________________________________________ Dolibarr-dev mailing list address@hidden https://lists.nongnu.org/mailman/listinfo/dolibarr-dev

reply via email to

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