Introduction
Le GrizzlyPack est un ensemble de composants pour Delphi.
Il s'installe pour les versions de Delphi de la 5 à la 7, et les paquets principaux ont été rendus compatibles jusqu'à la version 2007 grâce à PierreY.
Il représente le résultat du travail de plusieurs années à développer des applications de gestion diverses. Il est le fruit de mon travail mais aussi de mon frère Alexandre.
Un travail de documentation sera sans doute nécessaire à l'avenir...
Ces composants sont mis à la disposition de tous gratuitement et sans aucune restriction. Si vous souhaitez participer à leur amélioration, contactez-moi, pour que je vous donne un accès au référentiel SVN.
Installation
Ouvrez dans Delphi le paquet désiré selon votre version de Delphi.
Le paquet de base se nomme GrizzlyBaseDX.dpk avec X pour la version de Delphi.
Le paquet pour les composants spécifiques à QReport se nomme GrizzlyQRDX, aussi avec X pour la version de Delphi.
Si vous ne souhaitez installer que la partie "Dataset-mémoire et Dataset-pour-Firebird" il vous suffira d'installer les deux paquets nommés VDatasetDX.dpk et VDBDatasetDX.dpk.
ATTENTION
Une fois le paquet compilé et installé, pensez à ajouter le chemin des sources dans les options d'environnement de Delphi.
Téléchargement
Version 1.5 (Révision 195 du SVN) téléchargeable uniquement par FTP : (~500ko - 05/11/2007)
-
GrizzlyPack-V1_5.zip
- Pour les moteurs de recherche : Here, you'll be able to download the GrizzlyPack.
- Bis : Ici, vous allez pouvoir télécharger le GrizzlyPack.
Depuis peu (printemps 2007), le GrizzlyPack contient des composants complémentaires aux UIB permettant l'utilisation des composants DB de la VCL en lecture, mais aussi en écriture. Ils permettent d'une certaine façon de remplacer les IBX et autres IBO.
Les deux principaux composants ajoutés sont le TGzFBCachedDataset, pour accéder en lecture seule, mais avec toutes la souplesse du TVirtualDataset, et le TGzFBDataset, dans lequel il est possible de renseigner les ordres SQL à exécuter pour chaque modification (SQLInsert, SQLUpdate, SQLDelete, SQLRefresh).
Ces composants sont utilisés en production dans des situations particulières... mais ils n'ont pas encore connus suffisamment de situations complexes et différentes pour être réputés "hyper-stables". Cependant... je le répète : je les utilise pour les applications que je livre à certains de mes clients.
Je termine sur ce que je leur trouve d'intéressant :
- On peut utiliser les champs de type fkLookup sans soucis (si vous trouvez un cas tordu qui ne fonctionne pas, prévenez-moi).
- On peut utiliser les champs de type fkCalculated aussi.
- On peut après chargement des données, les retrier à l'envie, les index se calculant dynamiquement (propriété publique IndexFieldNames).
- On peut filtrer aussi sur tous les champs.
- On peut utiliser la propriété AsBoolean d'un TStringField avec une valeur différente que 'T' ou 'F'. Il faut pour cela utiliser la propriété "IsBoolean", et modifier dans votre projet les variables globales que l'on trouve dans l'unité TGzFBFields.
Il y a des faiblesses :
- Comme les données sont systématiquement totalement chargées à l'ouverture, il est déconseillé de faire des SELECT ramenant trop de lignes à la fois. La limite sera fonction de votre réseau, de votre machine, de votre serveur... de vos tests. J'avoue donc ne les utiliser que dans des cas où je ne sélectionne qu'un minimum de lignes, suivant les bonnes habitudes de tout bon développeur en Client/Serveur.
- La gestion des erreurs n'est pas encore au point dans certains cas limites.
- Le code des unités VDataset et GzFBDataset est un bordel sans nom... car je n'ai pas encore pris le temps de tout "ranger" suite aux différents ajouts de niveaux d'abstraction dans les objets.