darkBlog

Domino R6 introduit une nouvelle fonctionnalité qui est supposée "rendre les navigateurs plus intelligents" (fin de citation) en adaptant le format des dates au visiteur (parmi d'autres fonctionnalités qui ne nous intéressent pas ici). En clair, si on affiche la formule @Yesterday dans une page puis que l'on y accède avec un navigateur "français", on verra "02/03/2005" tandis qu'avec un navigateur "anglais" on obtiendra "03/02/2005". Pour déterminer l'origine de l'utilisateur, Domino se base sur l'entête HTTP Accept-Language.

Toutefois, pour peu qu'on utilise un navigateur dont la langue par défaut n'est pas le français (ce qui est mon cas, puisque j'utilise un Firefox US avec pour langage en-US), ce mécanisme d'adaptation des dates peut amener à de mauvaises interprétations des données : saisissez "02/03/2005" en songeant au 2 mars 2005, vous constaterez que Domino aura considéré le 3 février 2005.

Pour désactiver ce mécanisme, c'est facile, dans le 2e onglet des propriétés du champ date, choisir "Custom" plutôt que "User setting" pour l'option "Use preferences from". S'assurer ensuite dans les options qui suivent que le format de la date est bien le format désiré (dd/mm/yyyy j'imagine).

"User settings", paramètre par défaut, adapte
le format d'une date à l'utilisateur

Edit 1 an & demi plus tard: Il y a un paramètre dans le document de configuration serveur qui précise si Domino se base sur l'entête Accept-Language du navigateur ou la configuration du serveur. Plus de détails chez Jake, ou dans cet article de DW : Making Web browsers look smarter with Domino 6.

Lorsqu'on développe avec Domino, il est courant de se retrouver confronté à des situations dans lesquelles on aimerait bien pouvoir exécuter un agent après l'enregistrement d'un document (et non avant comme le permet l'événement [Web]QuerySave). Seulement voilà, si les masques possèdent bien un événement PostSave pour le coté client Lotus, il n'y a aucun événement WebPostSave en vue pour le web. Qu'à cela ne tienne, nous allons nous faire notre propre WebPostSave maison à coups de redirections !

L'idée va être la suivante : à l'enregistrement d'un document (création/modification), on va rediriger l'utilisateur vers un agent avec en paramètre une URL, l'agent s'exécutera puis, une fois son traitement terminé, tâchera de rediriger (à nouveau) l'utilisateur vers l'URL qu'on lui a initialement indiqué en paramètre.

Concrètement, si on souhaite exécuter l'agent agent-post-save après l'enregistrement d'un document, cela pourrait se traduire de la façon suivante : dans un masque, créer un champ calculé $$Return ayant pour valeur :

"[/test.nsf/agent-post-save?OpenAgent&redirect-to="+ @URLEncode("ISO-8859-1" ; "/test.nsf/0/"+ @Text(@DocumentUniqueID) +"?OpenDocument")+ "]"

Puis, dans l'agent LotusScript agent-post-save, une fois le traitement désiré terminé :

Dim session As New NotesSession
Dim contextDoc As NotesDocument
Dim redirectToEncoded As String
Dim redirectToDecoded As Variant

Set contextDoc = session.DocumentContext
redirectToEncoded = parse(contextDoc.Query_String(0), "redirect-to")
redirectToDecoded = Evaluate(|@UrlDecode("ISO-8859-1" ; "|+redirectToEncoded+|")|)

Print "["+redirectToDecoded(0)+"]"

Et voilà, l'affaire est dans le sac. Et tout ça sans la moindre ligne de Javascript, toutes les redirections étant serveur.

Au passage, ne cherchez pas la fonction parse(), c'est du code maison qui extrait des paramètres d'une Querystring. J'imagine qu'il ne vous sera pas trop difficile de faire la votre.