Le modèle d'objet SCRITERE

 

SCRITERE est un modèle destiné à faciliter la recherche d'informations. L'interface utilisateur est en général constituée d'un bandeau contenant les différents critères de recherche et d'une liste affichant les enregistrements de la table principale. Oxygène++ fournit deux modèles qui dérivent de SCRITERE. Ces modèles CHOIX et ACCES sont ceux préconisés pour la programmation orientée composant.

Les points forts du modèle SCRITERE sont les suivants :

- L'ergonomie du modèle est particulièrement intuitive pour l'utilisateur

- La programmation est très simple

- Les critères de filtre sont déduits directement de l'écran

- Les filtres peuvent être transmis de façon simple à un autre objet

- La simple modification de l'écran permet d'ajouter de nouveaux critères de recherche

Liste des déclarations standards

 

Liste des variables héritées et contexte de table

 

Liste des méthodes spécialisées

Fonctionnement du modèle

Les déclarations BASE et TABLE définissent la table principale utilisée par l'objet. C'est sur la table principale que les filtres de recherches seront posés.

La déclaration ECRAN est également indispensable. L'écran utilisé devra contenir au minimum une liste affichant les données de la table principale.

Au lancement de l'objet, une analyse de la structure de l'écran est déclenchée pour mettre en mémoire la liste des différents critères de recherche. Ces critères sont directement définis depuis l'éditeur d'écrans d'Oxygène++. Chaque contrôle (zone, case à cocher, combobox, etc) est susceptible de définir un critère de recherche.

A l'exécution, les actions de l'utilisateur sont analysées pour déterminer si elles modifient les filtres en cours. Si tel est le cas, les nouveaux filtres sont activés et la liste est actualisée. L'extension GererCaractere définie au niveau de l'écran permet d'activer l'actualisation de la liste à chaque frappe de caractère.

Définition des critères de recherche :

L'éditeur d'écrans d'Oxygène++ permet un stockage d'informations libres appelées "extensions". C'est cette fonctionnalité qui va permettre de définir les critères de recherche utilisés par SCRITERE. Pour définir les extensions d'un contrôle, il faut effectuer un clic-droit sur le contrôle (depuis l'éditeur d'écrans) et choisir la commande "Extension" du menu contextuel.

Le critère de recherche est défini grâce aux quatre mots clés que sont 'CodeChamp', 'Operateur', 'CodeVariable' et 'Tout'.

'CodeChamp' indique le code du champ sur lequel s'effectue l'opération de recherche.

'Operateur' définit l'opérateur utilisé. Les valeurs autorisés sont EgalA, InferieurA, SuperieurA, ApartirDe, JusquA, DebutePar, NeDebutePasPar, DifferentDe, Contient.

'CodeVariable' précise la variable contenant la valeur recherchée. Cette information est facultative. Si elle n'est pas définie le système prend automatiquement la variable définie sur le contrôle d'écran courant.

 'Tout' fournit la valeur pour laquelle aucun filtre ne doit être activé. La plupart du temps cette extension n'est pas utilisée, car le cas vide correspond au cas où tous les enregistrements doivent être affichés.

 

Exemple n° 1 :

 

Dans l'exemple ci-dessus, la table principale sera automatiquement filtrée comme si on avait tapé le code suivant :

 

 

Exemple n° 2 : avec utilisation de l'extension "Tout"

 

Programmation correspondante :

 

Les déclarations standards

BASE et TABLE :

Ces déclarations sont indispensables, elles définissent la table principale sur laquelle seront posés les filtres déduits de l'écran.

ECRAN :

Indique le nom de l'écran utilisé par l'objet SCRITERE. L'écran doit contenir un contrôle de type "liste" affichant les informations de la table principale.

- Notez ici, que les critères de recherche peuvent également être définis dans des écrans secondaires manipulés par les instructions EmpilerEcran et DepilerEcran du langage.

Les variables héritées du modèle

CodeListe :

Cette variable héritée définit le code de la liste à actualiser lorsque les critères de recherche sont modifiés. Si rien n'est précisé, le code "LST" est pris par défaut.

 

CodeClassement :

Cette variable héritée permet d'indiquer le classement à utiliser par défaut au démarrage de l'objet. Il peut être forcé par programme.

- l'utilisation d'un classement précisé directement dans les propriétés de la liste est ici déconseillé, car il entrerait en conflit avec celui choisi par le modèle.   - Même remarque pour l'instruction Classement du langage.

 

Les méthodes spécialisées du modèle

Méthode REMPLIT_CLASSEMENT :

Dans certain cas, on souhaite permettre à l'utilisateur de choisir lui-même le critère de classement. La méthode REMPLIT_CLASSEMENT est appelée par la méthode AVANT_DEBUT, elle met dans le contexte mémoire LISTEINDEX la liste des champs séquentiels indexés de la table principale.

Pour exploiter cette table mémoire, il suffit d'ajouter dans l'écran un contrôle de type 'Combobox' sur le contexte de table 'LISTEINDEX' (avec les colonnes LISTEINDEX.CODE et LISTEINDEX.LIBEL). La liste sera alors automatiquement classée sur le critère choisi par l'utilisateur.

 

Méthode ANALYSE_ECRAN :

Cette méthode ne doit pas être redéfinie. Elle analyse les extensions des contrôles de l'écran afin de mettre en mémoire la liste des filtres susceptibles être activés suivant les actions de l'utilisateur.

 

Méthode AJOUTE_CRITERE :

Paramètres :

Chaine code_champ

Chaine code_operateur

Chaine code_variable

Chaine valeur_tout // facultative

Elle permet d'ajouter par programme un critère de recherche qui n'a pas été défini dans l'écran. Cette méthode est particulièrement utile lorsque l'un des critères est implicite pour l'utilisateur ou lorsqu'une zone de l'cran travaille sur plusieurs filtres. Appeler cette méthode dans la méthode DEBUT.

- Dans un modèle SCRITERE, l'utilisation des instructions Filtre, Requete, DebutRequete, SuppFiltre et Classement ne doivent pas être utilisés sur la table principale. En effet, ces instructions perturberaient les automatismes du modèle.   - Par contre, l'utilisation de l'instruction "Rejeter" dans l'événement SELECTION associé à la liste est autorisée.

 

Exemple :

 

 

Méthode ANALYSE_SAISIE :

Les méthodes génériques du modèle ont été redéfinies afin que toute action utilisateur déclenche la méthode ANALYSE_SAISIE. Celle-ci détermine si la zone en cours est susceptible de modifier un critère de recherche. Si tel est le cas, elle fait appel à la méthode ACTIVE_REQUETE.

 

Méthodes ACTIVE_REQUETE et COMPARE_REQUETE :

La méthode ACTIVE_REQUETE est chargée de poser les filtres, de forcer le classement et d'actualiser la liste si les criteres de recherche ont évolué. Elle fait appel à la méthode COMPARE_REQUETE pour éviter de faire des affichages inutiles. Elle appelle également la méthode POSITIONNE_REQUETE juste avant l'affichage de la liste.

 

Méthode POSITIONNE_REQUETE :

Selon la nature des données traitées il est préférable de se positionner en début ou en fin de fichier. Le programmeur doit redéfinir POSITIONNE_REQUETE pour effectuer le positionnement adapté à son logiciel. Le positionnement sera fait en utilisant les instructions classiques telles que PositionnerDebut et PositionnerFin.

Par défaut, aucun positionnement n'est effectué. Le système conserve alors la position courante (sauf si elle ne correspond plus aux critères de recherche).

 

Methode ACTIVE_REQUETE_DEFINITIVE :

On a souvent besoin de transmettre à un autre objet les choix faits par l'utilisateur. Le modèle SCRITERE propose ici une solution astucieuse destinée à positionner les filtres sur un contexte de table appartenant à un autre objet.

L'objet qui souhaite récupérer les filtres du modèle SCRITERE doit prendre la main dans sa propre méthode INIT et procéder de la façon suivante :

 

 

Explications :

L'instruction AppliquerMethodeAppelant n'est utilisable que dans la méthode INIT. Elle rappelle automatiquement une méthode de l'objet appelant. Dans notre cas, la méthode en question reçoit en paramètre une chaîne indiquant le code du contexte sur lequel le filtre sera posé. Bien évidemment, le code du contexte passé doit faire référence à la même table que celle manipulée par l'objet SCRITERE. Si tel est le cas, la méthode ACTIVE_REQUETE_DEFINITIVE se charge de positionner les filtres et l'objet appelé n'a plus qu'à exploiter les données comme il l'entend.

 

Ce mécanisme est en général utilisé pour récupérer les filtres d'un objet à l'autre par exemple pour imprimer les données visualisées à l'écran sans passer en paramètre tous les critères de filtres et surtout sans reprogrammer le mécanisme du modèle SCRITERE.

 

Une autre technique pour transmettre des filtres est de les traduire en requête SQL et de passer cette chaîne en paramètre : utilisez les intrusctions LitRequeteSql et PoseRequeteSql.