Altova MobileTogether Designer

Le but de la recherche est de filtrer l’affichage des enregistrements pour qu’ils n’affichent que les livres pour lesquels le string de la recherche apparaît dans les champs de texte importants d’un livre ou d’un auteur. Si le string de la recherche apparaît dans un champ d’un enregistrement Authors - par rapport à un champ dans un enregistrement Books - alors tous les livres de cet auteur seront affichés.

 

La capture d’écran ci-dessous affiche les résultats d’une recherche pour le string « dark ». La recherche trouve deux livres. Dans les deux cas, le string de recherche apparaît dans le champ Title du livre.

Cliquez pour expansion/compression

 

Recherche locale vs. Recherche BD

La recherche peut être exécutée en local, sur un appareil mobile, dans les données qui ont été téléchargées de la BD ou elle peut être exécutée dans la BD du serveur. Chaque mécanisme a des avantages relatifs par rapport aux autres, tel qu’expliqué ci-dessous.

 

Si la recherche est exécutée localement, tous les enregistrements BD doivent être chargés dans la mémoire et recherchés. Ce mécanisme est plus rapide que si la recherche est effectuée dans la BD, mais il consomme plus de mémoire puisque tous les enregistrements doivent être gardés en mémoire, en particulier si la quantité des données de l’enregistrement des données de l’enregistrement est élevée.

Si la recherche est effectuée en envoyant une requête SQL à la BD, le temps pour les transactions avec la BD sera plus long. Toutefois, étant donné que seuls les enregistrements recherchés sont retournés, la consommation de mémoire pour l’entreposage des données sera inférieure.

 

Vous devrez peser le pour ou le contre des mérites quand vous décidez quel mécanisme se prête mieux pour un cas particulier.

 

Mécanisme

Il est possible de concevoir différentes approches pour la recherche. Le mécanisme que nous avons utilisé combine une recherche BD SQL avec une approche locale spécifique MobileTogether, nous l’avons décrit ci-dessous.

 

1.Le string de recherche est saisi dans Éditer champ.

2.Puisque Éditer champ est associé au nœud SearchText de la source de page \$PERSISTENT, le texte de recherche sera passé automatiquement à ce nœud quand le texte de recherche sera saisi dans Éditer champ (voir le nœud en surbrillance dans la capture d’écran ci-dessus)

3.En cliquant sur le bouton Find, deux actions sont exécutées en séquence : (i) la source de page \$BookCatalog est rechargée avec uniquement les enregistrements de ces Authors qui contiennent le string de recherche dans les données soit de l’auteur, soit de tout livre enfant (voir le Point 4 ci-dessous); (ii) une action Supprimer Nœud(s) supprime ces livres (des auteurs sélectionnés) qui ne contiennent pas de string de recherche dans ses champs, ne laissant que les livres de cet auteur qui contiennent le string de recherche (voir le Point 5 ci-dessous).

4.La recharge de la source de page déclenche une recherche dans la BD pour le string de recherche par le biais d’une instruction SQL. En conséquence, la source de page \$BookCatalog sera rechargée avec uniquement les auteurs pertinents (là où le string de recherche apparaît, soit dans les données de l’auteur, soit dans les données d’au moins un des livres de l’auteur). Voir la section Recherche SQL de la BD ci-dessous pour plus de détails.

5.Puisque la recherche SQL de la BD renvoie des auteurs avec tous leurs livres, les livres pour lesquels le string de recherche n’apparaît pas sont supprimés. Voir la section Supprimer des livres sans correspondance ci-dessous pour plus de détails.

 

Le string de recherche

Éditer champ a été créé dans lequel l’utilisateur peut saisir le string de recherche. Le champ Éditer champ.est associé avec le nœud \$PERSISTENT/Root/SearchText (en glissant-déposant le nœud dans Éditer champ). En conséquence, le texte de recherche sera stocké dans ce nœud, duquel il peut être accédé plus tard pour les actions.

 

Le bouton Find

La recherche est lancée quand on clique sur le bouton Find. Les actions de l’événement OnClicked du bouton (capture d’écran ci-dessous) sont (i) une action Recharger de la source de page \$BookCatalog et (ii) une action Supprimer Noœuds). Les deux actions actions sont décrites en détail ci-dessous. Pour le moment, il est important de savoir que l’action Recharger pour la source de page \$BookCatalog commence la recherche dans la BD. Voir la prochaine section, Recherche SQL de la BD. L’action Supprimer Nœud(s) est décrite dans la section Supprimer des livres sans correspondance ci-dessous

Cliquez pour expansion/compression

 

Rechercher SQL de la BD

Lorsqu’une action Recharger pour \$BookCatalog est déclenchée, une instruction SQL - dans chaque sélection de données de la source de page BD - sélectionne chaque ligne de la table Authors qui contient tout champ dans le texte de recherche (soit dans l’enregistrement Authors lui-même ou dans un des enregistrements Books associés à l’enregistrement). Cela s'effectue par le biais de l'étape suivante.

 

Configuration Source de page \$BookCatalog

La source de page \$BookCatalog a été configurée pour sélectionner tous les enregistrements de la table des Authors à l’origine, avec chaque enregistrement Authors contenant les enregistrements Books associés comme enfants. Maintenant, nous ajoutons une clause WHERE à l’instruction SQL afin de filtrer les enregistrements Authors pour sélectionner uniquement ces enregistrements où le terme de recherche apparaît. Puisque la clause WHERE doit être construite avec une expression XPath complexe, nous utiliserons une fonction pour mettre en œuvre l’expression XPath. La fonction est appelée DBSQLSearch(), tel qu’affichée dans la capture d’écran ci-dessous. Dans la capture d’écran, vous pouvez lire le instruction SQL dans le volet à côté du bas de la fenêtre. Dans cette instruction SQL, la clause WHERE sera la valeur envoyée de la fonction DBSQLSearch().

Cliquez pour expansion/compression

Note :pour éditer ou consulter la configuration de la source de page \$BookCatalog, cliquez sur l’icône Configuration de \$BookCatalog dans le Volet de sources de page.

 

 

Fonctions pour la recherche

Pour la recherche, nous créons deux fonctions : DBSQLSearch() et DBFieldsSearch(). Le dialogue Fonctions XPath pour créer ces fonctions est accédé par le biais de la commande de menu Projet | Fonctions XPath/XQuery et il est affiché dans la capture d’écran ci-dessous.

Cliquez pour expansion/compression

 

 

 

 

La fonction DBSQLSearch() fonctionne comme suit :

 

Si le texte de recherche n’est pas le string vide, alors l’instruction SELECT est créée utilisant la fonction DBFieldsSearch() deux fois : d’abord pour rechercher les champs de la table Authors, ensuite pour rechercher les champs de la table Books.

La fonction DBFieldsSearch() crée la clause WHERE pour recherhcer chaque table (Authors et Books) en référençant le mappage \$SearchFields de toutes les colonnes de la table de la BD. Le mappage \$SearchFields est stocké comme variable définie par l’utilisateur qui est accédée par le biais de la commande de menu Projet | Variables globales.

Autrement, tel que défini dans la fonction DBSQLSearch(), si le texte de recherche est un string vide, alors la clause WHERE de l’instruction SQL pour \$BookCatalog sera le string vide (voirla fonction DBSQLSearch() ci-dessus). Dans ce cas, de manière efficace, l’instruction SQL n’aura pas de clause WHERE, et tous les enregistrements Authors seront retournés.

 

La structure de l’instruction SELECT créée lorsque le string de recherche n’est pas vide est comme suit :

 

SELECT <AuthorsFields-1 to AuthorsFields-Z> FROM "Authors"

WHERE AF1 LIKE '%SearchText%' OR AF2 LIKE '%SearchText%' ... OR AFZ LIKE '%SearchText%'

OR Author_ID IN (SELECT AuthorID FROM Books

WHERE BF1 LIKE '%SearchText%' OR BF2 LIKE '%SearchText%' ... OR BFZ LIKE '%SearchText%')

 

Cette expression sélectionnera les enregistrements Authors qui ont soit un champ (i) Authors qui correspond au texte de recherche, soit (ii) un enregistrement Books associé qui a un champ correspondant au texte de recherche. Notez que si la recherche dans l’enregistrement Books associé renvoie une correspondance, alors l’enregistrement parent Authors est sélectionné.

 

Il est important de noter que puisqu’à la fin, les enregistrements Authors sont sélectionnés, ces enregistrements Authors seront sélectionnés avec leurs enregistrements Books associés - même si un ou plusieurs de ces enregistrements Books ne contiennent pas de texte de recherche. Comment afficher uniquement ces livres qui contiennent le texte de recherche est décrit dans la prochaine section, Supprimer des livres sans correspondance.

 

Supprimer des livres sans correspondance

Puisque les enregistrements Authors sélectionnés sont renvoyés avec tous all leurs enregistrements (enfant) Books associés (voir la discussion ci-dessus), les possibilités suivantes apparaissent :

 

Le texte de recherche est trouvé dans la table Authors. Dans ce cas, nous pouvons afficher les détails de l’auteur ensemble avec tous les enregistrements Books associés à cet auteur.

Le texte de recherche est trouvé dans une des tables associées Books d’un enregistrement Authors. Dans ce cas, nous allons devoir montrer les détails de l’auteur et les détails liés au/aux livre(s) correspondants uniquement. Un moyen d’y parvenir serait de supprimer les livres sans correspondance de la source de page \$BookCatalog. Dans notre exemple, nous y sommes parvenus en ajoutant une action Supprimer Nœud(s) au bouton Find une fois que la source de page a été rechargée (voir la capture d’écran ci-dessous).

Cliquez pour expansion/compression

 

L’expression XPath de l’action Supprimer Nœud(s) fonctionne comme suit :

 

La variable \$text contient une variante en minuscule du string de recherche. Ceci permettra que la recherche ne respecte pas la casse.

Les nœuds renvoyés pour être supprimés seront les enregistrements descendant Books de l’auteur actuel.

Les livres sélectionnés pour être supprimés doivent contenir tous les champs importants de Books. Ceci est précisé en créant une séquence de filtres de prédicats ; chaque prédicat est à l’intérieur de crochets. Tous les prédicats doivent être évalués comme true pour le livre pour se qualifier pour la suppression. Si un prédicat est évalué comme false (ce qui arriverait si le string de recherche existait dans le champ vérifié dans ce prédicat), alors l’enregistrement Books actuel n’est pas sélectionné pour être supprimé et le prochain livre est vérifié.

Veuillez noter que les filtres de prédicat ne vérifient non seulement les champs des enregistrements Books mais aussi les champs de l’enregistrement parent Authors (voir les trois derniers prédicats).

 

Supprimer le string de recherche

Une fois qu’une recherche a été réalisée, la source de page \$BookCatalog contiendra uniquement les enregistrements Authors et Books qui ont été renvoyés par le mécanisme de recherche décrit ci-dessus. Le bouton Clear (voir la première capture d’écran de cette rubrique) désactive le string de recherche et recharge la source de page \$BookCatalog pour qu’elle contienne tous les enregistrements Authors. Les actions du bouton Clear sont affichées dans la capture d'écran ci-dessous.

MTDTutDBHClearButtonActions

L’action Mettre à jour Nœud(s) change le nœud PERSISTENT/Root/SearchText pour qu’il puisse contenir le string vide. Puisque ce nœud est associé à Éditer champ dans lequel le texte de recherche est saisi, la valeur de string vide est affichée dans Éditer champ, effaçant Éditer champ (voir la section "Le String de recherche" ci-dessus). Recharger la source de page \$BookCatalog avec l’ensemble du nœud \$PERSISTENT/Root/SearchText vers le string vide charge tous les enregistrements Authors dans la source de page (voir la description de la fonction DBSQLSearch() ci-dessus).

 

© 2017-2023 Altova GmbH