15 bonnes pratiques pour développer en Rhinoscript sous Coheris

Afin de répondre à une question qui revient fréquemment chez nombre de consultant Coheris à propos du développement en Rhinoscript, voici un condensé de quelques bonnes pratiques à suivre. Ces ‘normes’ ne sont en aucun cas officielles mais elles permettent de garantir une unité dans vos développements et pour certaines règles d’améliorer les performances.

Nomenclature des fichiers et des fonctions

• Le nom du fichier doit commencer par RS_ (en majuscule)

  Coheris indexant les fichiers rhinoscript et javascript par la même extension .js, il convient de les différentier d’une autre façon. Le prefixe RS_ permet ainsi de comprendre au premier coup d’oeil qu’il s’agit d’un fichier Rhinoscript.

• Le nom de la fonction doit commencer par f_rs_ (en minuscule)

  Cette astuce est faite pour éviter de confondre le nom du fichier et celui de la fonction.

• Une fonction par fichier si possible

  Le nom du fichier étant directement lié au nom de la fonction, il est donc logique de ne pas regrouper plusieurs fonctions effectuant des traitements différents au sein d’un même fichier. Cela permet également de mieux ordonner les développements spécifiques. Une exception à ce système : les fichiers dits de bibliothèque qui sont regroupés autours d’un thème donné.

• Le template d’en-tête doit être renseignée

  Ceci permet de maintenir à jour la documentation sur votre fonction et de garder l’historique dessus si un autre développeur doit reprendre votre travail quelques temps après.

• Les variables locales doivent être déclarées par le tag ‘var’

  Trop souvent by-passé, la déclaration des variables est pourtant obligatoire. Rhino étant assez laxiste là-dessus, il est possible de s’affranchir de cette contrainte. Néanmoins, cette déclaration doit être faite dans un souci d’optimisation de la mémoire.

• Les variables globales doivent être préfixées par le tag ‘g_rs_’ et déclarées dans le fichier globalvars.js

  Une variable globale doit être déclarée en dehors de tout contexte de fonction et son nom doit être clairement identifiable. Trop souvent, ces dernières sont déclarées en bataille au milieu des fichiers et il devient alors impossible de les retrouver toutes dès lors qu’elle sont mal nommées. Une variable globale DOIT être déclarée de ce fait dans le fichier globalvars.js et dans aucun autre.

Appel de fonctions existantes

• Limiter l’utilisation de f_get_current_context

  Même si la facilité fait souvent appel à cette fonction, le contexte d’exécution rhino est précis. Il est donc possible la plupart du temps d’utiliser la fonction adéquate au lieu de celle-ci plus générique. Exemple : f_get_client_context, f_get_affaire_context, etc… Une exception cependant dans le cas de l’exécution d’une action qui peut s’effectuer depuis plusieurs contextes …

• Eviter l’utilisation de f_translate_sapi

  L’utilisation massive du SAPI dans le rhino est un facteur de ralentissement des performances. La plupart du temps, il est possible de récupérer la valeur souhaitée au travers de fonctions natives dédiées et optimisées pour cela.

• Utiliser (abuser de) f_get_field_value, f_get_element_value

  Ces 2 fonctions tombent naturellement sous le sens dès lors que l’on cherche à optimiser son code et à le rendre moins dépendant d’une chaîne SAPI. Attention en fonction de vos modifications sur le cache de DB ou IHM, vous devrez utiliser l’une OU l’autre de ces 2 fonctions.

• Utiliser f_rs_get_linked_field_value

  Pourquoi faire une requête en base et ajouter 20 lignes de codes supplémentaires pour récupérer la valeur d’un champ lié sur une table de référence quant cela peut être fait en une seule ligne à travers cette fonction très utile ?

Event Manager et designer

• Un évènement de l’event manager ne doit appeler qu’une seule fonction rhinoscript à la fois. Si plusieurs fonctions sont nécessaires au traitement, alors vous devez faire une fonction de routage.

  Là encore, il s’agit d’ordonner proprement vos développements et d’éviter les collisions de code. Dans le cas où vous renseignez plusieurs appels à des fonctions différentes sur un même évènement, il vous sera impossible de déterminer quelle fonction sera exécutée en premier. Il faut dans ce cas, faire une fonction rhino de routage qui appelle individuellement chaque fonction métier.

• Limiter l’appel direct à une fonction rhinoscript depuis le designer.

Comme mentionné précédemment, l’appel au SAPI est très consommateur de ressources. Dans le cas du SAPI placé dans le designer, l’effet est encore pire puisque la chaîne est recalculée à chaque demande d’affichage de l’écran et peut l’être pour chaque évènement lancé sur le contexte.

Logs

• Garder la même unité de log

Il est toujours très tentant de se faire sa propre fonction de log et ce pour chaque développeur. Ceci est très pratique pour la phase de dev mais inexploitable une fois en production. Il est donc très recommandé de faire une fonction globale de log et que chaque intervenant sur le code rhino s’y réfère. Dans le même ordre d’idée, tester le niveau des logs (info, debug, error) avant d’appeler une fonction de log permet d’améliorer les performances.

Pour résumer toutes ces bonnes pratiques pour développer en rhinoscript :

• Préfixer le nom du fichier par RS_
• Préfixer le nom de la fonction par f_rs_
• Ne mettre qu’une seule fonction par fichier
• Renseigner l’en-tête des fichiers
• Déclarer les variables locales avec le mot clé ‘var’
• Préfixer les variables globales par ‘g_rs_’
• Déclarer les variables globales dans globalvars.js
• Limiter l’utilisation de f_get_current_context
• Eviter l’utilisation de f_translate_sapi
• Utiliser f_get_field_value, f_get_element_value
• Utiliser f_rs_get_linked_field_value
• N’appeler qu’une seule fonction rhinoscript par évvènement depuis l’event manager
• Limiter l’appel direct à une fonction rhinoscript depuis le designer
• Structurer l’appel aux logs
• Tester le niveau de log

• 
•