darkBlog

Domino R6 dispose de 2 fonctions pour gérer l'encodage des URL : @URLEncode et @URLDecode. Toutefois, l'implémentation semble incomplète et certains caractères sont à priori ignorés, et notamment les (problématiques) simples quotes. N'oubliez donc pas, à chaque fois que vous encodez vos URL, d'encoder manuellement ces simples quotes :

@ReplaceSubstring(@URLEncode("Domino" ; sURL) ; "'" ; "%27")

Lorsqu'on intègre une vue dans un masque (rendu HTML) ou qu'on utilise un modèle de vue ($$ViewTemplate for masque), on peut avoir envie de mettre en place des fonctionnalités avancées comme accéder à la page suivante voire même - pour peu que l'on soit exigeant - accéder la page précédente.

Ceci peut se faire sans trop de difficulté avec une vue plate (avec une vue catégorisée ce n'est pas vraiment la peine d'y songer) en jouant avec les paramètres qui vont bien dans l'URL (voir à ce sujet l'URL Cheat Sheet), cela étant, c'est un peu dommage de se lancer si vite dans du bidouillage alors qu'il existe deux commandes qui permettent de le faire nativement : @DbCommand("Domino"; "ViewNextPage") et @DbCommand("Domino"; "ViewPreviousPage").

Toutefois (et c'est là l'information à retenir), si on omet de spécifier le paramètre count, indiquant le nombre de résultats désiré par page, dans l'URL (masque?Readform&count=XX ou vue?OpenView&count=XX), le fonctionnement de ces deux commandes se révèle plutôt bancal : les liens "page suivante" et "page précédente" amèneront respectivement (et directement) à la dernière page et à la première page, ce qui n'est pas tout à fait le résultat escompté ni désiré.

Vous me direz (n'est-ce-pas, que vous alliez me le dire ?) que c'est normal et qu'il est difficile d'imaginer un concept de navigation par pages quand on ne connait pas le nombre de résultats souhaité par page, et c'est tout à fait vrai dans le cas des modèles de vue, par contre, pour ce qui est des vues intégrées dans les masques, dans les propriétés de la vue intégrée il existe un champ précisément prévu à cet effet ("lignes à afficher"). Et c'est bien là toute la sounoiserie et la perversité de Domino, car ce champ rempli tout à fait son rôle pour la génération de la vue (ie: la vue compte bien le nombre de résultats demandé), cependant, la navigation entre les pages ne fonctionne pas correctement (voir le comportement décrit ci-dessus) !

Autrement dit, autant abandonner ce champ et utiliser uniquement le paramètre count qui lui fonctionne aussi bien pour la génération de la vue que pour la navigation entre les pages.

Et un immense merci à un ô combien brillant et mirifique collègue pour avoir trouvé la solution. Tu es le meilleur ! (et accessoirement, pour ceux qui se demanderaient, il est monté comme Schwarzenegger et il lui arrive de passer sur darkBlog).

La sécurité relative aux masques tient essentiellement en deux paramètres : l'accès par défaut aux documents créés avec le masque, et les personnes autorisées à créer des documents avec le masque. Le premier paramètre est clair, et joue peu ou prou le même rôle que les champs lecteurs, à la différence près qu'il s'agit de l'accès par défaut que les champs lecteurs permettent, au besoin dynamiquement, de redéfinir / surcharger.

Le second paramètre est toutefois plus ambigü. En effet, contrairement aux vues, il n'y a pas de paramètre du type "personnes autorisées à utiliser ce masque", ce qui peut surprendre, voire décevoir. C'est, en vérité, le rôle arboré par ce second paramètre, l'intitulé comme le libellé étant peu explicites et en partie incomplets. En réalité, il faudrait lire "Personnes autorisées à accéder au masque en édition (commande ?OpenForm) ET en consultation (commande ?ReadForm) pour l'intitulé, et "Dans le cas de l'accès en édition, tout utilisateur ayant au moins l'accès Auteur ET dans le cas de l'accès en consultation, tout utilisateur ayant au moins l'accès Lecteur" pour le libellé. C'est donc une même liste d'accès qui permet de spécifier les accès en édition et en consultation des masques. C'est regrettable, mais c'est comme ça.

Attention cependant, ces restrictions n'influent que sur l'accès physique au masque proprement dit. Il se peut (et il y a d'ailleurs de fortes chances) qu'il soit toujours "visible" au travers des documents qu'il a servi à créer, mais cela ne relève plus de la sécurité relative aux masques (et par conséquent plus de ce billet non plus).

Pour éditer des champs RTF sur le web avec Domino, vous pouvez utiliser soit l'applet Java native, soit un rendu purement HTML qui sera traduit par un bête textarea. Dans ce dernier cas, il est toutefois possible de mettre en place un éditeur tiers (comme HTMLArea), mais le sujet n'est pas là. Par ailleurs, dans tout masque, il est possible de définir le code Javascript correspondant à l'événement onSubmit du formulaire.

Il semblerait donc, au premier abord, tout à fait légitime de spécifier dans masque contenant un champ RTF (rendu applet Java) un traitement pour l'événement onSubmit. Seulement voilà, procéder de tel rend caduque l'utilisation de l'applet Java : les données qui y sont saisies ne sont plus enregistrées dans le document. La raison ? Le bon fonctionnement de l'applet Java nécessite un traitement à l'événement onSubmit du masque ; le code en question est d'ailleurs automatiquement généré par Domino : onSubmit="_getEditAppletData(); return true;". Du coup, si l'on colle du code pour ledit événement dans le masque en question, celui-ci écrase le code requis par l'applet Java. Le traitement post-saisie ne s'effectue pas, les données ne sont pas enregistrées.

Pour solutionner ce problème, c'est tout simple, il faut soit-même inclure l'appel à la fonction _getEditAppletData()" dans son traitement. C'était pas bien sorcier, encore fallait-il trouver l'origine du problème. Merci Domino, j'ai perdu pour ainsi dire une demi-journée.