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: Rasik Pandey
Subject: RE : RE : [sdx-developers] Changements récents
Date: Fri, 30 Apr 2004 13:14:22 +0200

Salut,


> Suis-je plus clair ?

Oui et non.

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

Oui, car les sous-objets d'une application pourraient en avoir besoin pour se 
configurer. D'ailleurs le Hashtable "fieldLists" et "repositories" deviendront 
un objet Context "readOnly" bientôt.

> des documentBases


non, rien à voir avec le "contexte" mais défini par le contrat d'un appli, ces 
sous-objets n'en ont pas besoin..... 

> une documentBase par défaut


> une base utilisateur

non, pour la même raison

> des thésauri

non, pour la même raison

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

Oui, car la plupart de ces membres ne sont pas stockées dans le "contexte" et 
elles ne devraient pas être stockées parce qu'on a un 
componentManager-->Framework-->Application qui définit comment cette 
communication typée devrait se passer.

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

Comme j'ai dit plus haut, ce n'est pas le cas. Je ne vois pas le "contexte" 
comme un objet pour centraliser tous les objets pour donner l'accès aux 
sous-objects, cette idée s'éloigne vraiment de IoC, non?. Je ne crois pas qu'il 
est une bonne idée de  faire deux lookups pour Application.getDocumentBase(id) 
=_context.get(documentBaseTable).get(id); ????  


A bientôt,

Rasik






reply via email to

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