|
From: | Laurent Destailleur (eldy) |
Subject: | Re: [Dolibarr-dev] Ajout de détails sur les articles - Notion d'attributs |
Date: | Sun, 19 Jun 2011 16:07:45 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 |
Le 19/06/2011 02:05, Régis Houssin a écrit :
Tout est question de vocabulaire."Ajout de détails sur les articles - Notion d'attributs" le titre du mail correspond aux déclinaisons de produits non ? ;-)) Je suggère le terme "champs complémentaires" pour l'ajout de champ personnalisé dans les écrans et le terme "déclinaison" pour les variantes de produits pour faciliter les compréhensions futures. Ceci est l'objet de la table llx_extrafields (anciennement nommé llx_adherent_option_label en 3.0).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 ? En effet cette fonctionnalité était déjà en oeuvre (partiellement) dans le module adhérent pour les champs personnalisés des adhérents. Je suis en train de renommer les tables pour avoir des noms plus générique. Ensuite je renommerais la classe adherent_options.class.php en extrafields.class.php 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 -- Eldy (Laurent Destailleur). --------------------------------------------------------------- EMail: address@hidden Web: http://www.destailleur.fr Dolibarr (Project leader): http://www.dolibarr.org To make a donation for Dolibarr project via Paypal: address@hidden AWStats (Author) : http://awstats.sourceforge.net To make a donation for AWStats project via Paypal: address@hidden AWBot (Author) : http://awbot.sourceforge.net CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net |
[Prev in Thread] | Current Thread | [Next in Thread] |