|
|
|
|
|
|
|
|
|
|
- Transformer une page en mode Session en une page AWP
- Conseils de programmation
- Bon à savoir
- Limitations concernant le contenu et la programmation des pages AWP
- Afficher une page AWP
- Installer des pages AWP sur un serveur
Créer et diffuser des pages AWP
Transformer une page en mode Session en une page AWP Pour transformer une page en mode Session en page AWP : - Sous l'éditeur, affichez la description de la page en cours (option "Description" du menu contextuel de la page).
- Dans l'onglet "Général", sélectionnez pour l'option "Type de page", le mode "AWP".
- Validez.
Où est enregistrée la page AWP ?
Après transformation d'une page dynamique en page AWP, la page sera générée au format AWP dans le répertoire <Nom Projet>_WEB du projet (dans chaque sous-répertoire correspondant aux langues gérées par le projet). Conseils de programmation - Le code serveur doit être présent dans les événements d'initialisation (initialisation de page ou de champs).
- Les contextes doivent être gérés par programmation. La page doit se positionner dans la base de données (par exemple en fonction des paramètres reçus dans l'URL). Pour plus de détails, consultez Afficher une page AWP depuis une autre page.
- Actualisation d'une page AWP : L'actualisation d'une page AWP déclenche l'intégralité des événements WLangage présents dans la page. Par exemple, si la page AWP permettait de faire un ajout, l'actualisation de la page refera cet ajout.
- Evénements WLangage : L'ordre d'exécution des événements WLangage lors d'un clic sur un champ Bouton par exemple est le suivant :
- Evénement "Initialisation" du projet,
- Evénement "Déclarations globales" de la page,
- Evénement "Initialisation" des différents champs de la page,
- Evénement "Initialisation" de la page,
- Evénement "Clic" du champ Bouton cliqué
A chaque action réalisée dans la page AWP, la page HTML correspondante est complètement reconstruite sur le serveur.
- Liens : Il est possible de construire des liens par programmation (propriété URL utilisée sur les champs Lien).
- Liens et boutons : Il faut préférer les liens et les boutons sans "submit". Un lien de type "<a href>" est généré dans la page.
Limitations concernant le contenu et la programmation des pages AWP - Première page d'un projet : Une page AWP ne peut pas être la première page du projet en mode Session. Une page AWP peut être la page d'accueil d'un projet.
- Fonctions WLangage de trace : Seule la sortie dans un fichier (constante trFichier) est disponible.
- Boîtes de dialogue : Les boîtes de dialogue affichées par les fonctions Confirmer, Erreur, Info ne sont pas prises en compte si une page est affichée dans le même traitement avec la fonction PageAffiche.
- Éléments globaux utilisés dans le projet : Lors de la modification d'un élément global au projet (procédure globale, requête, classe, ...), il est nécessaire de recompiler le projet pour prendre en compte ces modifications dans les pages AWP autonomes concernées.
- Réglettes : Les réglettes générées par le RAD ne peuvent pas être utilisées dans des pages AWP. En effet, ces champs utilisent le contexte du projet (qui n'existe pas dans les pages AWP). Ces champs doivent être remplacés par une réglette programmée. Chaque lien de la réglette doit afficher une page avec des données spécifiques (page basée sur une requête paramétrée par exemple).
Il est également possible d'afficher tous les enregistrements dans une cellule avec ascenseur.
La réglette en mode AWP gère automatiquement le passage de paramètres, sans programmation. Ce type de réglette permet le référencement de toutes les pages liées et évite l'usage de cookies pour mémoriser la recherche en cours. - Champ Table : Les champs Table sont limités (par exemple les tables fichier avec des colonnes de type Lien ne fonctionnent plus). Il est possible de les remplacer par une zone répétée (les liens étant construits dynamiquement avec la propriété Url).
- Champ Image : Une page AWP ne peut pas utiliser d'images générées.
- Elément en mémoire (Liste, combo, Zone répétée) : Le contenu de ces éléments est volatile. Il est conseillé de remplir systématiquement le contenu de ces éléments dans le code d'initialisation de la page.
- La valeur des champs en lecture seule est perdue et doit être recalculée à chaque affichage de la page.
- Taille des pages AWP : Dans des projets de taille importante (comprenant de nombreuses classes, procédures globales ou requêtes), les pages AWP générées auront une taille relativement importante.
- Variables globales serveur : Les variables globales serveur de projet reprennent leur valeur par défaut lors de chaque accès à la page dans le cas des pages AWP autonomes. Il est cependant possible d'utiliser la fonction DéclareContexteAWP ou des champs cachés associés à la valeur voulue.
- Composants WINDEV ou WEBDEV : Les composants manipulés par une page AWP ne sont pas trouvés. Il est nécessaire de les déplacer dans le répertoire <NomProjet>_WEB.
- Localisation des fichiers de données : La localisation des fichiers de données doit être réalisée dans le code d'initialisation du projet, par exemple par la ligne de code :
HSubstRep("?", fRepDonnées())
- URL relative : Les URL relatives construites par programmation dans la page d'accueil du projet ne doivent pas être utilisées.
Une page AWP peut être affichée depuis une page statique ou depuis une page en mode dynamique d'un site WEBDEV. L'affichage d'une page AWP peut être effectué : - soit par l'interface de WEBDEV : il suffit de sélectionner la page AWP à afficher lors de la description du lien.
- soit par programmation.
Installer des pages AWP sur un serveur Pour installer des pages AWP sur un serveur, il est possible : - soit d'utiliser l'installation classique d'un site en mode Session. Les fichiers AWP sont classés dans la catégorie "Fichiers HTML statiques".
- soit d'utiliser WDDeploy ou tout autre client FTP pour mettre le fichier directement sur le site voulu.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|