Mar 14/02/2012 - Actualités

Xavier
Administrateur du site
Messages : 817
Enregistré le : mer. 22 juin 2011 18:25

Mar 14/02/2012 - Actualités

Message non lu par Xavier »

Mar 14/02/2012 - Actualités


08:40

La structure des données ne devait pas entrainer de limitation du Design, en tous cas pas si tôt :
XMo a écrit :
FBu a écrit : ...
pour l'instant, tout est déplié et non repliable: la liste des contacts est affiché avec toutes les infos visibles. A partir de quelques contacts créés, le scroll est obligatoire.

Est-ce qu'on aura une option pour ne pas voir les infos par défaut (juste la liste des contacts sans tout le détail déplié) ?
...
Par contre je ne vais pas pouvoir stocker l'état "ouvert" / "fermé" de chaque Contact. Il y aura donc une option permettant de choisir entre "tout fermé et "tout ouvert". La navigation dans les dossiers réinitialisera l'état des Contacts "ouverts".
La classe actuelle contient un nombre défini de champs stockés, et un champ Term utilisable pour y stocker des Properties, qui sont des chaines de format Property=Value :

Code : Tout sélectionner

	// TData
	TData = class(TObject)
		// Champs de la hiérarchie
		Parent: TData;
		Container: Boolean;
		Children: TList;
		Tag: LongInt;

		// Champs du stockage
		OID: String;
		Creation: TDateTime;
		Update: TDateTime;
		Encryption: Boolean;
		Model: String;

		// Champs des données (Cryptables)
		IconFile: String;
		IconIndex: Integer;
		Caption: Array[0..1] of String;
		Term: TStringList;

		// Champs spécifiques aux Tools (Internes, non stockés)
		Created: Boolean;
		Ready: Boolean;
		Visible: Boolean;
		end;
Historique:
  • Le champ Term était initialement destiné à recevoir des textes entiers, comme ceux de l'outil Notes.
  • Cependant, afin de gérer les options via ces objets, la notion de Property a été ajoutée et elles ont naturellement été stockées dans ce champ qui était disponible, les options n'étant pas destinée à stocker des textes.
  • Par la suite, durant le développement de l'outil Contacts, des Properties ont également été stockées dans le champ Term. Ce choix de facilité a été une erreur, car du coup le système ne permettra pas de stocker les Notes.
La classe des données va donc être modifiée comme suit :
  • La champ Term va être renommé en Text et sera réservé aux données utilisateurs : les Informations d'un Contact, le texte d'une Note, etc.
  • Une nouvelle liste de chaines appelée Properties sera ajoutée, elle sera réservée... aux Properties. (Cela permettra entre autres de stocker l'état "ouvert" / "fermé d'un Contact.)
  • Les champs stockés actuels qui ne sont pas universellement utilisés (IconFile, IconIndex) vont être déportés en Property.
  • Certains champs qui ne seront finalement pas utilisés seront supprimés (OID, Creation et Update).
Il va donc y avoir un peu de rework mais il vaut mieux faire ça maintenant et avoir une structure la plus souple possible pour de futurs besoins.
Denis
Messages : 180
Enregistré le : jeu. 23 juin 2011 09:21

Re: Mar 14/02/2012 - Actualités

Message non lu par Denis »

Yes bien! Les torchons avec les torchons et les serviettes avec les serviettes !!
Je te conseilles juste de conserve le champ OID, il sera utile pour identifier les doublons lors export-import.
Xavier
Administrateur du site
Messages : 817
Enregistré le : mer. 22 juin 2011 18:25

Re: Mar 14/02/2012 - Actualités

Message non lu par Xavier »

DMo a écrit :Yes bien! Les torchons avec les torchons et les serviettes avec les serviettes !!
Je te conseilles juste de conserve le champ OID, il sera utile pour identifier les doublons lors export-import.
Oui, l'OID devait servir à gérer les conflits, de même que les dates de création et de modification.

Mais il n'y aura finalement aucun conflit à gérer, la procédure d'import créera un dossier et y stockera toutes les données importées, la propagation dans les dossiers finaux étant à la charge de l'utilisateur.
Répondre