Altova MobileTogether Designer

Les solutions d'exemple 04-EditRecords.mtd et 05-EditRecordsOnStart.mtd sont des exemples qui expliquent comment éditer des données hors ligne et se mettre en ligne uniquement pour enregistrer des données vers une base de données sur le serveur.

Elles sont situées dans le dossier de (Mes) Documents : Altova\MobileTogetherDesigner8\MobileTogetherDesignerExamples\Tutorials\OfflineUsage. Ouvrez les fichiers dans MobileTogether Designer et exécutez des simulations (F5) pour voir comment elles fonctionnent.

Les deux solutions enregistrent les données dans une base de données SQLite sur le serveur, AddressesIndexed.sqlite. La solution 05-EditRecordsOnStart.mtd n'est différente de 04-EditRecords.mtd qu'à un seul égard : les enregistrements de la base de données SQLite sont affichés à l'écran d'accueil de la solution.

Description des exemples de solution

L'exemple de solution 04-EditRecords.mtd (design affiché dans la capture d'écran ci-dessous) affiche les données de BD dans la table et permet aux utilisateurs d'éditer les données. Les champs de la table sont liés à la source de page \$PERSISTENT. Ceci signifie (i) que les contenus de \$PERSISTENT sont affichés dans la table, et (ii) que les éditions que vous réalisez dans la table sont stockées dans \$PERSISTENT.

Lorsque la solution 04-EditRecords.mtd démarre, la table est vide (voir la capture d'écran ci-dessous). C'est le cas puisque la table a \$PERSISTENT en tant que sa source de page et \$PERSISTENT sont vides. Veuillez également noter que la source de page \$DB1 est vide. C'est le cas puisque elle a également été définie en tant que Charger des données = Pas automatiquement. Dans le volet des Sources de page, cliquez avec la touche de droite sur \$DB1 pour voir la valeur de son paramètre Charger les données.

Dans la solution, les éditions de données suivantes sont possibles :

•Un nouvel enregistrement (ligne) peut être ajouté à la table et les champs de l'enregistrement peuvent être édités. Pour ajouter une nouvelle ligne, cliquez sur l'icône Plus située à droite de la dernière ligne (voir les captures d'écran ci-dessus et en dessous). Après avoir ajouté une nouvelle ligne, les données de la ligne sont stockées dans \$PERSISTENT (voir la capture d'écran ci-dessous).

•Dans la solution, une ligne peut être supprimée en cliquant sur l'icône de la ligne Moins (voir la capture d'écran ci-dessus).

•Les données dans \$PERSISTENT peuvent être enregistrées sur le serveur en cliquant sur Enregistrer dans base de données. Voir la section Enregistrer des données éditées en utilisant des clés primaires et OriginalRowSets ci-dessous.

•En cliquant sur Refresh (encerclé en rouge dans la capture d'écran ci-dessous), toutes les lignes de données sont téléchargées depuis le serveur vers \$DB1 et copiées de là vers \$PERSISTENT (voir les actions de l'événement OnPageRefresh tel que défini dans l'onglet événement). Toute donnée présente dans \$PERSISTENT avant le Refresh sera supprimée. Puisque les lignes dans \$PERSISTENT sont affichées dans la table, celle-ci affiche désormais tous les enregistrements du serveur. Les actions exécutées  pour un événement OnPageRefresh sont définies dans l'onglet de l'événement. Veuillez noter que l'Accès au serveur pour \$DB1 a été défini en tant que Sur demande. Ceci assure que le serveur ne sera contacté que si une requête est envoyée à celui-ci, comme celle pour recharger les données de la base de données. Ceci signifie en effet que les utilisateurs peuvent travailler hors ligne jusqu'au chargement des données vers le serveur.

Paramètres clés

Les paramètres clés de la solution (04-EditRecords.mtd) sont donnés dans la table suivante.

Au démarrage de la solution, charger toutes les données pour l'édition

Lorsque la solution 04-EditRecords.mtd est lancée, la table est vide parce que \$PERSISTENT est vide. Si nous souhaitons montrer toutes les données BD du serveur dans la table, nous pourrions utiliser la stratégie suivante, qui a été utilisée pour 05-EditRecordsOnStart.mtd. Pour voir comment elle a été définie, ouvrez 05-EditRecordsOnStart.mtd et consultez la définition de l'événement OnPageLoad à la page de la solution.

1.Puisque les actions que nous souhaitons exécuter doivent être réalisées lors du démarrage de la solution, nous les créons dans l'événement OnPageLoad de la page d'accueil de la solution.

2.Recharger \$DB1 par le biais de l'action Recharger. Ceci télécharge toutes les données BD depuis le serveur vers \$DB1 (lors du démarrage de la solution).

3.Supprimer tous les enregistrements de \$PERSISTENT par le biais de l'action Supprimer nœud(s).

4.Copier tous les nœuds d'enregistrement de \$DB1 à \$PERSISTENT. en utilisant l'action Mettre à jour nœud(s). Une fois que les données ont été ajoutées à l'arborescence \$PERSISTENT, elles seront automatiquement affichées dans la table. Ceci est dû au fait que les commandes dans les cellules de table ont des liens de sources de page vers les nœuds de la source de page \$PERSISTENT.

Enregistrer des données éditées en utilisant des clés primaires et OriginalRowSets

Dans 04-EditRecords.mtd et 05-EditRecordsOnStart.mtd, le paramètre pour créer un nœud OriginalRowSet a été défini en tant que true. Ce paramètre est activé par le biais d'une commande de bascule dans le menu contextuel de la source de page. Dans les deux exemples, à chaque fois que la page est actualisée (par le biais du bouton Refresh), la source de page \$DB1 est chargée une nouvelle fois depuis le serveur et deux étapes importantes sont exécutées : (i) un nœud OriginalRowSet est créé dans \$DB1 qui contient une copie complète exacte dans le nœud RowSet de l'arborescence (c'est-à-dire de toutes les lignes du serveur BD), et (ii) les nœuds RowSet ainsi que OriginalRowSet sont copiés de \$DB1 à l'arborescence \$PERSISTENT. De cette façon, nous savons quelles lignes étaient présentes à l'origine dans la table avant le début de l'édition : les lignes éditées sont dans RowSet, alors que les lignes d'origine se trouvent dans OriginalRowSet.

Si la table est donc modifiée, c'est-à-dire si de nouvelles lignes sont ajoutées ou supprimées, alors le nombre de lignes dans RowSet et OriginalRowSet sera différent dans \$PERSISTENT. Chaque ligne est identifiée par un champ de clé primaire unique intitulé ID, qui ne peut pas être NULL et est automatiquement défini en tant qu'entier incrémenté automatiquement.

Lorsque les données sont enregistrées sur le serveur BD, le mécanisme d'enregistrement est le suivant :

1.\$DB1 est rechargé en utilisant l'action Reload.

2.Depuis \$DB1/RowSet, les lignes qui ont la même ID que celle des lignes dans \$PERSISTENT/OriginalRowset sont supprimées. Ceci permet la suppression de toutes les lignes d'origine (avant la modification) de \$DB1/RowSet.

3.Les lignes de \$PERSISTENT/Rowset sont copiées vers \$DB1/RowSet. avec l'action Ajouter nœud(s). Il s'agit des nouvelles lignes éditées et des lignes non éditées dans \$PERSISTENT/Rowset que nous voulons enregistrer sur le serveur. Les lignes qui ont été supprimées de la table ne seront pas dans cet ensemble de lignes, et ne seront donc pas copiées dans \$DB1. En conséquence, \$DB1 contiendra désormais uniquement les lignes que nous voulons enregistrer de retour sur le serveur.

4.Une action Enregistrer enregistre les données de \$DB1 à la base de données SQLite sur le serveur, en enregistrant uniquement les modifications.