Commentaires de pouicky sur tout CodeS-SourceS

10 commentaire(s) de pouicky sur des sources sur tout CodeS-SourceS

Le : 13/05/2006 16:01:13
Source : UTILISATION DES DATAMODULES ET DE LA VCL POUR IMPLÉMENTER UN PATTERN OBSERVER OU NON

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.

Le : 08/05/2006 21:49:45
Source : DESIGN PATTERN OBSERVER : IMPLÉMENTATION RÉUTILISABLE

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

Le : 07/05/2006 15:49:39
Source : DESIGN PATTERN OBSERVER : IMPLÉMENTATION RÉUTILISABLE

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.

Le : 01/05/2006 21:57:52
Source : DESIGN PATTERN OBSERVER : IMPLÉMENTATION RÉUTILISABLE

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

Le : 01/05/2006 12:27:40
Source : DESIGN PATTERN OBSERVER : IMPLÉMENTATION RÉUTILISABLE

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?

Le : 28/02/2006 23:25:49
Source : INITIATION AU TREEVIEW POUR DÉBUTANT

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 : 04/02/2006 12:35:34
Source : DBGRID AVEC ZONE DE RECHERCHE,TRI,FLECHES,MEMOS,MOLETTE,COULEURS

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

Le : 15/12/2005 23:06:06
Source : DBGRID AVEC TRI SUR CLIC, MOLETTE ET COULEURS

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

Le : 15/12/2005 18:48:00
Source : DBGRID AVEC TRI SUR CLIC, MOLETTE ET COULEURS

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

Le : 15/12/2005 18:26:28
Source : DBGRID AVEC TRI SUR CLIC, MOLETTE ET COULEURS

En fait ce Destructeur est un reste d'un essai avec un TEdit que je voulais gérer dans ce composant. J'avais commenté le code qui ne fonctionnait pas et effacé ensuite.. Il reste le "Inherited destroy...".
Question: Comment gérer un TEdit qui serait inclus dans ce composant ?
En considérant que le owner du TPersoDBbgrid est le owner du TEdit? et en écrivant un constructeur:
TPersoDBGRID.Create(owner)
begin
...
Edit:=TEdit.Create(Owner)
...
end;?
ou plutôt(mais je ne crois pas que c'est possible)
TPersoDBGRID.Create(owner)
begin
...
Edit:=TEdit.Create(self)
...
end;
???
Si quelqu'un a une piste, c'est pour faire apparaître une zone de recherche sur les en-tetes de colonnes au dblClic