Le fichier ADUtils permet(sous reserve de modifications au niveau d'un compte d'acces à l'AD d'un domaine) de lire trouver si l'utilisateur courant fait partie d'un groupe.
Si l'utilisateur fait partie d'un groupe G_Requeteur ou G_requeteurSelection, alors le logiciel poursuit.
Il n'y a plus qu'à tester la validité des comptes d'acces aux données "en dur" (choix que j'ai fait vu que les comptes d'acces de nos logiciels ne changent pas.

Cela me permet de laisser cet outil à disposition des utilisateurs sans leur fournir de mot de passe, et de gérer l'acces en les incluant ou non dans les groupes G__Requeteur ou G_RequeteurSelection de l'Active Directory.

En résumé,pas utilisable sans Annuaire LDAP. Et du boulot de personnalisation dans le cas contraire.

Tu as pu ouvrir les sources, malgré que le zip soit corrompu?

Une discussion intéressante a déjà eu lieu sur le sujet:
http://www.developpez.net/forums/showthread.php?t=76749&highlight=metier

Une question à cent balles sur la source:
Comment synchroniser l'affichage de deux fiches de film lorsqu'il s'agit du même film, et pas lorsqu'il s'git de films différents?
--> je pencherais vers la tenue d'une liste par  la fiche "liste de films" (car cette fiche peut avoir la vision des sous-fiches instanciées) et la recherche dans cette liste de l'identifiant base du film pour voir si il est déjà affiché. Si oui, alors on  répercute les modification faites, différents doubles.

Mais si on garde la possibilité de permettre plusieurs fiches de liste, il faut transposer cette astuce sur leur TDatamodule commun, unique qui aura un liste exhaustive.

j'ai planché et ai buté sur des impasses dans le cas du pattern observer avec sgbd. Puis je me suis aperçu qu'avec la vcl et ses controles de données, on fait du pattern observer sans le savoir. J'ai essayé de jouer avec les datamodules et les composants ado et ai posté un code qui illustre deux manieres d'utiliser les datamodules pour des comportement "observer" ou "non observer". Je ne sais pas si c'est dans les "bonnes pratiques" mais ça permet de reflechir.. http://www.delphifr.com/codes/UTILISATION-DATAMODULES-VCL-POUR-IMPLEMENTER-PATTERN-OBSERVER-OU_37511.aspx

Que tu t'interesses à la question est dejà super. Je m'aperçois en effet que pour ce qui est des données, le pattern observer a d'autre implications. Et je me prépare à poster une source sur la réutilisation du code et découplage entre objets et interface dans une application simple en delphi (elle sera imparfaite, et illustrera donc les problemes posés, et peut-etre d'autres)
j'attends tes pistes avec impatience ;). Ce qui manque plus que la technique sur ces problemes c'est l'expérience et j'en manque cruellement.

Dans l'exemple, il ya 2 fiches Releves et Stats prévues pour observer, et ayant un constructeur qui enregistre leur membre observateur aupres du sujet observable passé en parametre.

Or l'exemple illustre 2 manieres de gérer l'inscription des observateurs au sujet : Pour la fiche de stat, c'est la fiche principale qui l'inscrit sur son propre FObservable. Alors que pour la fiche de releves c'est le constructeur qui inscrit la fiche sur le membre FObservable de la fiche relevé (j'essaie de résumer, et on est bien d'accord que les membre FOBservables des deux fiches sont le même objet, non?).
N'y a t'il pas alors deux inscriptions pour la fiche de stats?
pour verifier cela j'ai saisi testé cela dans l'unité Uobservable

procedure TObservable.AddObserver(Obs: IObserver);
begin
  if FObservers.IndexOf(Obs) = -1 then
    FObservers.Add(Obs);
    ShowMessage(inttostr(fobservers.Count));
end;

procedure TObservable.RemoveObserver(Obs: IObserver);
begin
  if FObservers.IndexOf(Obs) <> -1 then
    FObservers.Remove(Obs);
    ShowMessage(inttostr(fobservers.Count));
end;
et il y a  un truc bizarre : le clic sur "listing" est cohérent mais le clic sur "statistiques" provoque deux passages dans AddObservers et avec la meme valeur pour Fobservers.count (s'enregistre sans incrementation?? ya t'il une transmission sans traitement de la liste des observateurs entre la fiche principale et la fiche de stats?)

Un super tuto qui élève l'esprit sur des horizons plus larges

J'en avais vu qui expliquaient la méthodologie Composition ou bien le méthodologie interface, mais là tout s'éclaire. Cependant, je me penche en ce moment sur MVC plus prisé en langages web, mais qui me semble tres lié au pattern observer. J'espere que le probleme que je pose maintenant tombe à propos:
Mon but est de faire une appli qui puisse changer de base de données avec un minimum d'efforts. (exemple Le SQL de Oracle et le SQL d'access, qui ne sont pas les mêmes).
Je pense décomposer l'appli en trois parties (Modele-Vue-Controleur:
1- Une classe de composants d'acces aux données (un module qui pourrait etre interchangé selon le sgbd et/ou l'architecture) - Le Modèle
2- Les objets "métiers" qui appelleraient des methodes de cette classe d'acces aux données (composition de composants)-Le controleur
3- Les formulaires qui observeraient les objets métiers, et implementeraient l'ergonomie- la vue

Or tout ce petit monde serait sujet et observateur des autres.
L'interface devrait se tenir au courant de l'état de la base de données et de l'état des objets métiers
Les objets doivent se tenir au courant de l'état de la base et de l'interface lorsque l'utilisateur agit.
Il y aura les acces aux données faits par les objets métiers
Il y aurait les acces aux données par les fiches (dbgrid relié par exemple) (pas tres souhaitable dans l'optique MVC)
Il y aurait autant de commandes sql à envoyer que d'objets modifiés + le retour des resultats à gérer.

Questions:
-Doit-on limiter les rôles sujets observateurs au minimum pour les performances ou cela altere t'il tres peu la fluidité d'une appli.?
-Les meilleurs choix sont il de "mapper les tablesBDD avec des composants DBTables ou plutôt d'utiliser un composant par type d'action :Objet"command", objet "Query" qu'on réutiliserait pour les differents acces??

Je n'aime pas trop les datamodules pleins de TABLES avec Maitre/esclave qui semblent trop proches de la base.
Dans quelles mesures peut on compter sur la puissance des composants BDD de delphi pour refléter l'état des données?
N'ayant pas d'expérience sur le sujet, quelqu'un peut-il m'indiquer une piste?

tres bien, l'interface, surtout pour la gestion des icones, j'avais la flemme de m'y mettre.
Un tres bon point de départ pour se lancer dans la programmation du treeview.
Merci, j'aime partir de morceaux de code de base et là il y a tout ce qu'il faut.
remarque: j'ai dû ignorer un message d'erreur "propriété nodedata n'existe pas ", ou un truc comme ça mais ça passe en ignorant.
10 sur 10 car il tient bien ses promesses en illustrant diverses possibilités.

Le zip a été mis à jour, il contient
*le code du composant mis à jour (avec fonction d'export CSV et disponibilité d'un évènement)-> pas de .dfm, il faut installer le composant comme décrit dans l'explication

*un projet de test avec le .dfm de la fiche de test

*un fichier groupe de projet pour manipuler la source du composant et lancer le projet de test facilement. (ouvrir avec le bloc note et modifier le chemin des projets du groupe le cas échéant)

Bon test

Je me réponds apres avoir cherché dans quelques forums et suivi quelques mauvaises pistes:
sur le oncreate du composant TPERSODBGRid j'instancie un TEDIT:
eTests :=TEDit.Create(self)
Et j'enchaine aussitôt avec eTests.Parent:=self;
et là le TEdit est géré par son papa le TPersoDBGrid (propriété "visible:=True" possible alors que non si je ne faisais pas celà).
Merci de m'avoir guidé, même sur une fausse piste, ça permet de pousser le bouchon en étant confiant(je n'aurais pas testé ça sinon)
Un nouvelle version de la TPersoDBGRid pour bientôt?...

En fait la source que tu m'indiques n'est pas celle d'un composant, et la gestion du owner n'est pas à faire. C'est bien cela qui m'est difficile: sur quel evenement, par quel détour je dois instancier puis faire réagir mon TEdit inclus dans le PersoDBGrid (en remontant par le owner ou directement avec le PersoDBGrid)??