A partir de la version 27, WEBDEV propose un mode session avec pages référençables. Ce mode permet de référencer les pages tout en profitant des avantages du mode session :

• rapidité puisque entre deux appels, la session reste en mémoire sur le serveur,
• facilité de programmation puisqu'il n'est pas nécessaire de gérer à la main les variables de session.

Pour plus de sécurité, il n'est pas nécessaire de référencer toutes les pages en mode Session : le développeur choisit les pages à référencer.

• Pour chaque page, nécessité de se reconnecter à la base de données, de recharger les variables d'état du site, etc. : les pages sont un peu plus longues à s'initialiser et cela augmente la charge sur le serveur de base de données.
• Les données nécessaires à l'identification de l'internaute et à la "session" en cours doivent être conservées dans le "contexte AWP" en utilisant la fonction WLangage DéclareContexteAWP. Pour certaines variables complexes, il est nécessaire d'effectuer une sérialisation ce qui alourdit d'autant les traitements.
• Difficulté pour sécuriser les parties "privées" du site, chaque page étant adressable directement. Il est donc nécessaire de vérifier si l'utilisateur est connecté et s'il est autorisé à accéder à la page.

Présentation

Cette page d'aide donne une méthode de conversion d'un site AWP vers le mode "session référençable" en détaillant les différentes étapes à suivre.

1. Changement du type de site.
2. Choix des pages à référencer.
3. Suppression du code de gestion du contexte AWP.
4. Choix des images à référencer.
5. Modification du code de construction des URL.
6. Suppression du code de vérification de connexion.

1. Changement du type de site

Le site étant en mode AWP, il est tout d'abord nécessaire de changer le type du site pour le passer en mode Session :

1. Affichez la fenêtre de description du projet : sous le volet "Projet", dans le groupe "Projet", cliquez sur "Description".
2. Dans l'onglet "Projet" de la fenêtre de description du projet, dans la zone "Type de site", sélectionnez "Session".
   
3. Dans l'onglet "Avancé", vérifiez que la case à cocher "Ne pas déconnecter les utilisateurs inactifs" est bien décochée. Cette option n'est pas compatible avec les pages en mode session référençable.
4. Validez la fenêtre de description du projet.

2. Choix des pages à référencer

Dans le site en mode Session, il est nécessaire de choisir les pages qui vont être ou non référençables. En effet, toutes les pages d'un site ne doivent pas obligatoirement être référençables. Il est possible également de parler de pages "adressables" : ces pages pourront être retrouvées par leur adresse et si le contexte associé existe toujours, le contenu pourra être affiché.

• les pages de la boutique doivent bien sûr toutes être accessibles directement et référencées.
• les pages du composant interne "PageEspaceClient" n'ont pas besoin d'être accessibles ou référençables puisqu'il s'agit d'une partie privée du site. Cette partie du site doit être accessible uniquement après connexion.
• les pages du composant interne "PageVenteEnLigne" constituent le tunnel de conversion (l'ensemble des pages qui gèrent le panier utilisateur et la vente elle-même). Ces pages n'ont donc pas besoin non plus d'être référencées.

1. Affichez la fenêtre de description de la page : sous le volet "Page", dans le groupe "Description", cliquez sur "Description".
2. Dans l'onglet "Général" :
   • Sélectionnez le type de page : "Session".
   • Si la page est référençable, cochez l'option "Référençable". Si nécessaire, modifiez le nom à utiliser dans l'URI.
     
3. Validez.

3. Suppression du code de contexte AWP

En mode AWP, les variables à conserver entre deux appels de page sont enregistrées dans le "contexte AWP".

1. Le contexte est initialisé avec la fonction WLangage ConfigureContexteAWP. Par exemple :
   
   // Déclaration d'un contexte AWP
   ConfigureContexteAWP(ctxDisque, ctxIDCookieURL)
   
2. Les variables à placer dans le contexte AWP sont enregistrées avec la fonction WLangage DéclareContexteAWP.
   
   // Est-ce qu'un client est connecté ?
   DéclareContexteAWP(gnClientEnCours)
   

4. Choix et paramétrage des images à référencer

Pour les images, il faut également choisir si elles doivent être référençables ou non.

1. Le champ Image ne doit pas utiliser le "mode de compatibilité". Pour vérifier le mode de gestion du champ Image :
   • Affichez la fenêtre de description du champ Image.
   • Dans l'onglet "Détail", vérifiez et modifiez si nécessaire l'option "Mode de compatibilité". Cette option doit correspondre à "Aucun".
2. Si le champ Image utilise un mode d'affichage spécifique (étirement, homothétie, ...), pour que cette image soit référençable, l'affichage doit être calculé par le navigateur. Inversement, pour qu'une image ne soit pas référençable, l'affichage doit être calculé par le serveur dans la session en cours.
   • Affichez si nécessaire la fenêtre de description du champ Image.
   • Dans l'onglet "Général", vérifiez le mode d'affichage de l'image. Modifiez si nécessaire le mode de transformation de l'image pour que la transformation soit réalisée côté "Navigateur".

• Pour une image avec une transformation effectuée côté "serveur", l'image doit être affectée au champ en indiquant le chemin du fichier image sur le disque. Pour connaître le répertoire des images, utilisez les fonctions WLangage fRepDonnées ou fRepWeb.
  Rappel : dans ce cas, l'image ne sera pas référençable car elle est calculée par le serveur dans la session en cours.
• Pour une image avec une transformation effectuée côté "navigateur", l'image doit être affectée en utilisant l'URL de l'image. Il est possible d'utiliser :
  • une URL absolue. Une URL absolue est une URL qui commence par "http://", "https://" ou uniquement "://" (pour utiliser le même protocole que la page).
  • une URL relative. Dans ce cas, WEBDEV considère qu'il s'agit d'une URL relative au répertoire "_WEB" du projet. Les images doivent donc être placées dans ce répertoire (ou un sous-répertoire).
    Dans le cas d'une application multilingue, il est possible de placer les images dans un sous-répertoire par langue.

5. Modification du code de construction des URL

En mode AWP, pour construire une URL par programmation, l'URL peut contenir l'identifiant du contexte AWP. Cet identifiant est connu grâce à la fonction IdentifiantContexteAWP.
Un exemple de code utilisé :

• La fonction IdentifiantContexteAWP n'a plus de sens.
• L'identifiant de la session en cours est tout de même nécessaire. Si cet identifiant n'est pas présent dans l'URL, une nouvelle session sera créée sur le serveur (ce qui n'est pas le but).

• une première partie automatiquement stockée et transmise dans un cookie,
• une seconde partie conservée dans l'URL, dans un paramètre nommé "REFID". Pour rester dans la même session, ce paramètre doit être conservé.

Dans ce cas, pour construire l'URL d'une page, il suffit d'utiliser la fonction WLangage PageAdresse.
Cette fonction ajoute automatiquement à l'URL de la page la valeur en cours du paramètre REFID.

• vérifier si le code contient des constructions d'URL de pages réalisées par programmation. Les cas les plus fréquents sont :
  • l'affectation de la propriété URL de certains champs (champ Arbre, champ Lien, ...).
  • le remplissage du champ Chemin de Navigation.
  • l'appel à la fonction WLangage ScriptAffiche.
  Ce code doit donc être modifié pour utiliser la fonction WLangage PageAdresse.
• vérifier que les liens construits mènent à des pages "référençables".
  Pour une page qui n'a pas la propriété "référençable" activée, l'accès à la page ne peut pas se faire par un lien : il doit être réalisé via la fonction PageAffiche.

6. Suppression du code de vérification de connexion

En mode AWP, si le site comporte une partie protégée par une connexion (comme un espace client par exemple), il est nécessaire de vérifier par programmation, avant l'affichage de chaque page de cette partie protégée, qu'un client est bien connecté.
Le code suivant est souvent utilisé :
En mode session référençable, il suffit d'indiquer que ces pages ne sont pas référençables.
Le code qui vérifie qu'un client est bien connecté peut donc être supprimé.