sdx-developers
[Top][All Lists]
Advanced

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

Re: RE : [sdx-developers] Changements récents


From: Pierrick Brihaye
Subject: Re: RE : [sdx-developers] Changements récents
Date: Fri, 30 Apr 2004 12:11:17 +0200
User-agent: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:1.0.2) Gecko/20030208 Netscape/7.02

Salut,

Rasik Pandey a écrit:

C'est la responsabilité de l'objet qui va utiliser le FieldList à définir 
comment réagir à l'absence de l'objet FieldList.

Oui.

Ça devrait être déjà le cas, sinon c'est un bogue...

Oui.

On est d'accord et ça devrait être le cas aujourd'hui.

Oui... et non. Je pense qu'on ne se comprend pas bien. j'explique (pour Application.Java).

Est-ce qu'on est d'accord que :

/** The repositories owned by this application (i.e. application-level repositories). */
private Hashtable repositories;
/**The fieldList(s) defined at the application level*/
private Hashtable fieldLists = null;
/** The document bases owned by this application. */
private Hashtable documentBases;
/** The default document base. */
private DocumentBase defaultDocumentBase = null;
/** The user database. */
private UserDatabase userDatabase;
/** The list of thesauri*/
private Hashtable thesauri = new Hashtable();

... sont des points d'accès vers des "services" ? Namely :

une fieldList globale
des documentBases
une documentBase par défaut
une base utilisateur
des thésauri

Au tout début, je me suis dit que c'était une bonne solution même si j'aurais préféré des accesseurs :

getFieldList, setFieldList
get docuentBases, set documentBases

Avec le nouveau "contexte", je me demande si ces "membres" (je ne les appelle pas "propriétés" pour ne pas confondre avec l'ancien objet "properties") sont encore utiles.

Si configure() trouve un objet de ce type, il le met dans le contexte, s'il ne le trouve pas, il ne le met pas. C'est marche *effectivement* comme ça mais, dans ce cas... à quoi servent ces variables ? Un lookup dans le contexte n'est-il pas suffisant ?

Naturellement, les trucs "non-débranchables" (i.e. ogligatoires) devraient (should) rester comme variables d'instance. Je n'en vois que 2 et encore, on peut en discuter :

documentBases
defaultDocumentBase

Suis-je plus clair ?

A+

--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden
+33 (0)2 99 29 67 78





reply via email to

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