Utiliser le mode contextuel

version 2003 (Modifiée)

Le serveur Web de 4D peut fonctionner dans deux modes distincts : le mode sans contexte (mode standard) et le mode contextuel. Cette section présente ces deux modes et détaille les particularités du mode contextuel.

Attention : Le mode contextuel peut être utilisé avec 4D en mode local et 4D Server uniquement. Le serveur Web de 4D en mode distant ne prend pas en charge ce mode.

Note : La section Premiers pas présente un exemple complet de publication d'une base en mode contextuel.

Mode sans contexte et mode contextuel

Le serveur Web de 4D utilise par défaut le mode sans contexte (mode déconnecté). Dans ce mode, le fonctionnement du serveur Web 4D est comparable à celui des serveurs Web standard : lorsqu'il reçoit une requête HTTP d'un navigateur (URL, formulaire posté, etc.), le serveur traite la requête puis retourne éventuellement une réponse (envoi d'une page Web par exemple). Aucune connexion spécifique n'est maintenue par la suite entre le serveur et le navigateur.

En mode sans contexte, le serveur Web peut envoyer des pages statiques ou des pages semi-dynamiques. Les pages semi-dynamiques permettent d'accéder aux données de la base ou d'effectuer tout type de traitement via des balises 4D spéciales, évaluées au moment de l'envoi de la page. Les pages semi-dynamiques vous permettent de construire, gérer et envoyer des pages Web dont le contenu est en totalité ou en partie issu d'un traitement effectué par 4D. Le mode sans contexte permet généralement de répondre à la plupart des besoins de développement de sites Web.

En mode contextuel, la connexion d'un navigateur Web provoque la création d'un contexte, dans lequel il dispose de sa propre sélection courante, de ses variables, etc. En quelque sorte, chaque navigateur est considéré comme un 4D Client se connectant à la base en mode Application. Le contexte est pris en charge par un process de connexion Web spécifique.

Ce mode permet de publier instantanément une base 4D sur le Web, sans qu'il soit nécessaire de créer des pages Web : 4D génère et envoie au navigateur des pages dynamiques, issues de la conversion automatique en HTML des barres de menus et des formulaires de votre base. En mode contextuel, il reste toutefois possible d'envoyer des pages semi-dynamiques ou des pages statiques. Il est également parfaitement possible d'insérer du code HTML ou Javascript dans les formulaires 4D afin d'ajouter des fonctions aux pages affichées sur le Web.

En outre, dans ce mode 4D gère automatiquement les accès simultanés aux données : lorsqu'un navigateur ou un poste 4D Client charge un enregistrement, 4D le verrouille de manière transparente pour les autres utilisateurs, qu'ils soient navigateurs ou postes 4D Client. De plus, 4D vous permet d'effectuer la saisie de données au sein d'une transaction avec un navigateur Web, comme avec 4D. Ce système permet au serveur Web 4D de contrôler parfaitement les actions des navigateurs et de garantir l'intégrité des données.

En contrepartie de cette facilité de publication, le mode contextuel inclut quelques contraintes :

- les navigateurs Web permettent de "surfer" d'une page Web à une autre, d'un site à un autre, etc. Avec une base de données en client/serveur, cette navigation doit être contrôlée afin de respecter la logique des transactions de la base. Chaque saisie effectuée par un utilisateur dans un enregistrement doit être validée ou annulée afin de ne pas rester dans un état incertain. Le moteur de serveur Web 4D contient des mécanismes automatiques de gestion des sessions et des contextes de la base. Ces mécanismes empêchent l'utilisation de certaines fonctions standard des navigateurs (Recharger, Page précédente, etc., cf. paragraphe suivant).

- le process de connexion chargé de maintenir le contexte reste actif jusqu'à ce que la période d'inactivité (timeout) du navigateur spécifiée dans les Préférences de la base soit atteinte. Si par exemple le navigateur a quitté le site entre-temps, le contexte est alors "gaspillé".

Ces contraintes destinent plutôt le mode contextuel à une utilisation en Intranet ou dans le cadre d'applications Internet spécifiques.

Le principe de fonctionnement du serveur Web 4D est résumé dans le schéma suivant :

Le choix du mode de fonctionnement du serveur Web de 4D s'effectue soit :

• au démarrage du serveur, via l'option Mode de démarrage des Préférences,

• au cours de l'utilisation du serveur Web, en fonction des URLs envoyés ou des commandes exécutées.

En effet, certains URLs spéciaux et certaines commandes 4D provoquent le changement du mode. Le principe est que le mode courant reste utilisé tant qu'aucun URL ou aucune commande 4D ne provoque un changement de mode.

Par défaut, le serveur Web démarre en mode sans contexte. Vous pouvez démarrer le serveur Web directement en mode contextuel. Cela signifie que lorsqu'un utilisateur se connecte à la base, un contexte est automatiquement généré.

Pour définir le mode sans contexte au démarrage, cochez l'option Mode contextuel (contexte permanent) dans le thème Web, page Configuration de la fenêtre des Préférences de la base :

Au cours de l'exploitation de la base, vous pouvez changer de mode lors de l'appel des éléments suivants :

• Passage en mode sans contexte :

- ENVOYER BLOB HTML en passant Vrai dans le paramètre optionnel sansContexte

- ENVOYER TEXTE HTML en passant Vrai dans le paramètre optionnel sansContexte

- ENVOYER REDIRECTION HTTP

- URL débutant par /4DACTION

• Passage en mode contextuel :

- URL débutant par /4DMETHOD/MaMéthode.

Lorsque l'URL /4DMETHOD/MaMéthode est envoyé, le serveur Web 4D crée un nouveau contexte et effectue les opérations suivantes :

	- la Méthode base Sur authentification Web est exécutée (si elle existe),
	- la Méthode base Sur connexion Web est exécutée (si elle existe) — dans ce cas particulier, $<1 est égal à /<4DMETHOD/MaMéthode au lieu de / (barre oblique),
	- enfin, la méthode demandée est exécutée dans le contexte nouvellement créé.

En fonction des actions qu'ils effectuent, certains process Web utilisent des contextes Web, d'autres n'en utilisent pas.

Vous pouvez connaître le nombre de contextes générés, à l'aide de la commande INFORMATIONS PROCESS : pour tout process Web, cette commande indique dans le paramètre origine s'il utilise un contexte (-11, Process web avec contexte) ou non (-3, Process web sans contexte).

Le numéro du process de la connexion Web s'appelle le numéro de contexte. C'est un nombre, généré aléatoirement, qui identifie chaque connexion Web. Le numéro de contexte est géré par 4D et par le navigateur pendant toute la connexion Web. Dans l'exemple ci-dessous, le numéro de contexte est 1738227136. Dans la fenêtre de votre navigateur Web, le numéro de contexte apparaît dans l'URL affiché dans la zone de destination :

Les URLs sont automatiquement gérés par 4D pendant toute la session Web en mode contextuel. Chaque fois qu'une requête HTTP est reçue via TCP/IP, 4D extrait le numéro de contexte de l'URL, et peut donc réacheminer la requête au bon process de connexion Web.

Les numéros de contexte permettent à 4D :

• de gérer les sessions Web et celles de la base de données,

• de gérer de façon transparente plusieurs connexions Web simultanées,

• d'éviter des connexions indésirables futures utilisant des marqueurs "Favoris", car un numéro de contexte différent est généré à chaque connexion.

Dans la fenêtre précédente, vous pouvez constater que le numéro de contexte est suivi d'un point et d'un autre chiffre. Ce second chiffre s'appelle le numéro de sous-contexte. 4D gère et incrémente automatiquement ce numéro chaque fois qu'une nouvelle page HTML issue de 4D est envoyée au navigateur en mode contextuel. Le numéro de sous-contexte est essentiel à la gestion de la session de la base.

Généralement, un navigateur Web dispose de contrôles de navigation comme des boutons du type 'Page précédente' ou 'Page suivante', des fenêtres d'historique, etc. Ces contrôles sont utiles lorsque vous consultez des documents, des notes d'information, des listes, etc. Ils sont moins efficaces lorsque vous effectuez une transaction à partir de la base.

Par exemple, si un utilisateur Web ajoute un enregistrement à une table, il faut savoir si la saisie des données a été validée, c'est-à-dire si l'utilisateur Web a cliqué sur le bouton Annuler ou Valider dans le formulaire 4D. Si, à ce stade, l'utilisateur Web appelle d'autres pages HTML, la saisie reste dans un état incertain. Pour cela, 4D utilise le numéro de sous-contexte afin de synchroniser la session Web côté 4D.

Lorsqu'un formulaire est soumis au navigateur ou qu'une requête HTTP est envoyée à 4D par le navigateur, si une désynchronisation des sessions du Web et de la base est détectée, 4D envoie le message "En utilisant les contrôles de navigation du navigateur, vous n'avez pas validé les données d'un formulaire. 4D va revenir sur ce formulaire afin que vous le validiez ou l'annuliez". 4D retourne alors à la page Web de saisie à l'aide du numéro de sous-contexte.

La synchronisation est également essentielle pour le process de connexion Web. L'exécution d'une commande telle que, par exemple, AJOUTER ENREGISTREMENT ([...]) doit s'achever correctement pour que l'on puisse continuer à utiliser la base.

La synchronisation est sélective. Si la page Web courante affichée dans le navigateur est un formulaire 4D (AJOUTER ENREGISTREMENT, VISUALISER SELECTION, DIALOGUE, etc.), les contrôles de synchronisation se manifesteront le cas échéant.

Si la page Web courante est une page HTML statique issue d'un lien présent dans une autre page Web (et envoyée à l'aide de la commande ENVOYER FICHIER HTML), vous pouvez naviguer librement parmi ces pages.

Considérons les lignes de code 4D suivantes :

   AJOUTER ENREGISTREMENT ([Clients])
   ENVOYER FICHIER HTML ("Page.HTM")
   VISUALISER SELECTION ([Produits])

Le schéma suivant décrit ce qui se passe sur 4D et sur le navigateur Web lors de l'exécution de ce code :

• les lignes rouges signalent les différentes transmissions du formulaire 4D.

• les lignes bleues signalent le transfert entre les pages HTML basées sur 4D et celles qui ne le sont pas.

• les lignes vertes indiquent des pages HTML qui ne sont pas basées sur 4D.

Description des étapes

(1) La commande AJOUTER ENREGISTREMENT est appelée. 4D traduit le formulaire entrée courant de la table en une page HTML et l'envoie au navigateur Web. Si le formulaire contient plusieurs pages, les boutons de navigation standard de 4D permettent de naviguer parmi les pages du formulaire. La navigation est implémentée et effectuée par 4D de façon transparente (via la soumission de formulaire Web).

(2) Pendant la saisie des données (donc dans l'appel à AJOUTER ENREGISTREMENT), l'utilisateur Web clique sur un bouton. La méthode objet du bouton appelle la commande ENVOYER FICHIER HTML.

(3) A la suite de l'appel à ENVOYER FICHIER HTML, si la page HTML contient des liens, l'utilisateur peut naviguer parmi différentes pages. Finalement, lorsque l'instruction ENVOYER FICHIER HTML("") est exécutée, le mode HTML est terminé.

(4) L'exécution de la méthode objet du bouton sur lequel l'utilisateur a cliqué et de la saisie des données liée à AJOUTER ENREGISTREMENT reprennent. Notez que les étapes (2) et (3) peuvent être répétées plusieurs fois pendant la saisie des données.

(5) Enfin, la saisie des données est soit validée soit annulée et le process de connexion Web est exécuté.

(6) L'appel suivant est ENVOYER FICHIER HTML.

(7) Cet étape est semblable à l'étape 3. Si la page HTML contient des liens, il est possible de naviguer parmi plusieurs pages. Lorsque finalement la commande ENVOYER FICHIER HTML("") est appelée, le mode HTML est terminé.

(8) Le process de connexion Web est exécuté.

(9) La commande VISUALISER SELECTION est appelée. 4D traduit le formulaire sortie courant de la table en page HTML et l'envoie au navigateur Web. Pendant le VISUALISER SELECTION, 4D permet de naviguer de façon transparente entre la page de sélection et l'affichage séparé de chaque enregistrement. 4D peut également utiliser MODIFIER SELECTION pour gérer la saisie des données et le verrouillage des enregistrements, par l'intermédiaire des formulaires Web.

(10) Pendant qu'il navigue parmi les enregistrements de la sélection, l'utilisateur clique sur un bouton dans la zone de pied de page du formulaire. La méthode objet du bouton appelle la commande ENVOYER FICHIER HTML.

(11) Cette étape est semblable aux étapes 3 et 7. Si la page HTML contient des liens, il est possible de naviguer parmi plusieurs pages. Lorsque finalement la commande ENVOYER FICHIER HTML("") est appelée, le mode HTML est terminé.

(12) L'exécution de la méthode objet du bouton sur lequel l'utilisateur a cliqué et l'affichage de la sélection liée à AJOUTER ENREGISTREMENT reprennent. Notez que les étapes (10) et (11) peuvent être répétées plusieurs fois pendant la navigation dans la sélection.

(13) Enfin, l'affichage de la sélection est terminé et le process de connexion Web est exécuté.

Et ainsi de suite...

La navigation Web libre (lorsque par exemple vous cliquez sur les boutons Suivant ou Précédent) est possible au sein de tout appel à ENVOYER FICHIER HTML (les zones vertes dans le schéma ci-dessus). En revanche, toute page HTML basée sur 4D (saisie des données, affichage de la sélection..., y compris les boîtes de dialogue standard telles que celles qui sont affichées par les commandes CONFIRMER ou Demander) échappe aux contrôles standard du navigateur. A l'issue de la navigation, 4D va, si nécesssaire, synchroniser les sessions Web avec celles de la base en revenant à la page Web dont le numéro de sous-contexte correspond à celui de la commande en cours d'exécution dans le process de connexion Web.

De son point de vue, l'utilisateur pilote la session Web à travers ses actions dans le navigateur Web. Du point de vue de la programmation, c'est le process de connexion Web qui pilote la session Web, et non l'inverse. Le navigateur Web affiche les pages envoyées par le process de connexion Web qui :

• soit exécute du code 4D,

• soit attend du navigateur le retour de la page Web courante.

Du point de vue du mode Développement, le process de connexion Web doit être considéré comme un process 4D dont le domaine d'exécution est 4D ou 4D Server, mais dont l'interface utilisateur est située sur le navigateur Web distant. En conséquence, tenez toujours compte de la dualité du process de connexion Web lorsque vous développez des applications pour le Web en mode contextuel. Par exemple :

• Lors de la saisie de tout type de données, la barre de menus principale est celle du navigateur, pas celle de 4D. Dans un formulaire, ne comptez pas sur la barre de menus de 4D ; elle apparaît sur la machine du serveur Web, mais pas sur la machine du navigateur Web.

• Lorsque vous créez des formulaires à destination du navigateur Web, rappelez-vous que les fonctionnalités du formulaire 4D sont restreintes à celles du HTML (avec cependant quelques possibilités supplémentaires liées à 4D). Il n'est donc pas possible d'employer toutes les fonctionnalités des formulaires de 4D (par exemple, tous les types d'objets ou tous les événements formulaires). Pour plus d'informations sur ce point, référez-vous ci-dessous au paragraphe "Conversion HTML automatique".

• En ce qui concerne la communication interprocess, la commande APPELER PROCESS n'a pas d'effet lorsqu'elle est appliquée à un process de connexion Web, car le formulaire actif est affiché sur le navigateur Web. En revanche, un process de connexion Web peut exécuter un APPELER PROCESS à destination d'un autre process 4D. De plus, la communication interprocess peut s'établir indifféremment dans les deux sens, par l'intermédiaire des commandes LIRE VARIABLE PROCESS et ECRIRE VARIABLE PROCESS, qui ne nécessitent pas la présence d'une interface utilisateur pour le process.

Durée de conservation des process Web inactifs (Timeout)

Comme décrit précédemment, un process de connexion Web en mode contextuel soit exécute du code 4D, soit attend le retour de la page Web en cours d'affichage sur le navigateur. Dans ce second cas, le process de connexion Web accordera au navigateur un délai de réponse égal à la valeur de l'option Durée de conservation des process Web inactifs, que vous fixez soit dans le thème Web, page Avancé de la fenêtre des Préférences de la base, soit à l'aide de la commande FIXER TEMPORISATION WEB.

La portée de ce paramétrage est la session de la base. Tous les process de connexion Web contextuels sont assujettis à cette valeur ; ils sont immédiatement affectés lorsque le paramétrage est modifié. La valeur par défaut est 5 minutes.

Note : La commande FIXER TEMPORISATION WEB vous permet de définir une valeur de timeout par process Web.

Vous pouvez augmenter ou réduire cette valeur à votre convenance. Par exemple, vous pouvez augmenter la temporisation si votre application permet aux utilisateurs Web de naviguer vers d'autres sites Web via des liens HTML dans les pages de votre base. En augmentant la temporisation, vous permettez aux utilisateurs de naviguer plus longtemps parmi d'autres sites Web sans fermer les connexions à votre base.

ATTENTION : Il n'est pas possible de stopper par programmation le process de connexion Web. Si vous spécifiez une temporisation longue, le process attendra ce délai même si l'utilisateur Web s'est déconnecté de la base depuis un certain temps. Si vous cochez l'option Ouverte en permanence, les process de connexion Web ne s'arrêteront que lorsque vous quitterez la base.

A noter toutefois qu'un process de connexion Web est automatiquement tué dès que le serveur Web passe en mode sans contexte.

A la différence du process serveur Web, les process de connexion Web peuvent être tués à l'aide de la commande Tuer (disponible dans l'Explorateur d'exécution de 4D lorsque la page Process est affichée).

Ce paragraphe précise les éléments, objets et mécanismes pris en charge automatiquement lors de la conversion de la base en HTML par 4D en mode contextuel.

• Chaque barre de menus est transcrite dans une page HTML. Chaque menu apparaît comme du texte seul et les commandes de menu associées à des méthodes 4D apparaissent comme des liens vers ces méthodes 4D. Les commandes de menu uniquement associées à des actions automatiques apparaissent comme du texte seul.

• Cliquer sur une commande de menu dans le navigateur Web déclenche, dans le process de connexion Web, l'exécution de la méthode 4D associée.

Note : Lorsque la propriété "Démarrer un process" est associée à une commande de menu, la méthode associée est exécutée par le serveur Web de 4D dans un nouveau process de connexion Web, à l'aide de l'URL 4DMETHOD. Dans ce cas, la méthode du menu doit disposer de l'attribut Disponible via 4DACTION, 4DMETHOD et 4DSCRIPT (non coché par défaut pour les nouvelles bases). Pour plus d'informations, reportez-vous à la section Sécurité des connexions.

• Une image associée à une barre de menus est placée au-dessous des menus sur le navigateur.

• 4D conserve au maximum la position initiale de chaque objet du formulaire. Notez cependant que le HTML est une application orientée traitement de texte : le positionnement relatif des objets pourra être légèrement différent sur le navigateur.

• Les formulaires multi-pages (y compris la page zéro et les formulaires hérités) sont gérés de manière transparente.

• Les actions automatiques, lorsqu'elles sont cohérentes, sont supportées de manière transparente.

• Les événements formulaires Sur chargement, Sur libération, Sur clic et Sur minuteur sont gérés. Les autres événements ne le sont pas.

• Les balises d'en-tête, de corps, de rupture et de pied de page sont prises en compte lors des appels à VISUALISER SELECTION et MODIFIER SELECTION. L'en-tête du formulaire s'affiche une fois au début de la page HTML, le corps est répété autant de fois que nécessaire et les variables (telles que les boutons) sont placées dans le pied de page à la fin de la page HTML, juste en-dessous des liens automatiques de navigation dans la sélection.

• Les info-bulles des boutons affichés en images dans l'éditeur de formulaires apparaissent sur le navigateur — si celui-ci en permet l'affichage.

• Une image répliquée (affichage Mosaïque) insérée en coordonnées (0,0,x,x) dans l'éditeur de formulaires de 4D est envoyée comme image de fond au navigateur. A noter toutefois que les images sombres sont à éviter.

Note : Le serveur Web 4D utilise les CSS1 (Cascading Style Sheet 1) pour générer des pages HTML dont l'apparence est très proche de celle des formulaires obtenus dans 4D. Ces "feuilles de style en cascade", définies par le consortium W3C (World Wide Web Consortium), contiennent un ensemble de caractéristiques définissant l'apparence d'un document : police de caractères, taille, couleur, titres, texte courant, interlignage, etc. Les documents .CSS sont envoyés avec le type MIME "text/css". En mode contextuel et en mode sans contexte, ces documents ne sont pas analysés par 4D.

Pour des raisons de compatibilité, vous pouvez choisir, à l'aide de la commande FIXER PARAMETRE BASE le mode de conversion Web à utiliser pour les formulaires.

Lorsqu'un formulaire 4D est converti en page HTML, les champs sont traduits de la manière suivante :

(*) ou Texte seul si non-saisissable

(**) si la valeur de type Texte se compose de plusieurs lignes

(***) si la valeur de type Texte ne se compose que d'une ligne ou est vide

Note : Les variables saisissables se comportent comme les champs du même type.

Lorsqu'un formulaire 4D est converti en page HTML, les objets de formulaire sont traduits de la manière suivante :

Les objets suivants ne sont pas convertis en HTML et sont donc ignorés :

Liste hiérarchique, Menu déroulant hiérarchique, Sous-formulaire, Bouton radio image, Thermomètre, Règle, Cadran, Menu image, Bouton image, Case à cocher 3D, Bouton radio 3D, Séparateur.

Notes

1. Les lignes non horizontales ne sont pas supportées par le HTML ; elles sont donc ignorées.

2. Les boutons non-visibles sont des objets de type Bouton invisible, Bouton inversé, Bouton 3D et Grille de boutons. Lorsqu'une image statique ne chevauche aucun bouton non-visible, elle est traduite comme une image statique. Si elle chevauche au moins un bouton non-visible, elle est traduite comme une "image interactive" gérée sur le serveur (Server-side Image Map).

Sur le navigateur Web, l'image est traitée comme une Server-side Image Map. Du côté de 4D, lorsque le formulaire est reçu, 4D recalcule la position du clic pour générer un événement Sur clic pour le bouton correspondant, comme si l'utilisateur avait réellement cliqué sur le bouton. Gérer des boutons non-visibles est donc très simple, dans la mesure où ils recouvrent ou sont recouverts par des images statiques. Vous contrôlez ces boutons dans la méthode formulaire ou dans leurs méthodes objets, tout comme vous le faites pour l'interface 4D standard. C'est aussi un moyen simple de gérer l'interactivité des images Web (Web Image Mapping). Si un bouton non-visible ne chevauche aucune image statique, il est ignoré lors de la conversion.

3. Le regroupement des boutons radio est maintenu lors de la conversion.

4. Les zones de défilement groupées ne sont pas supportées par le HTML. 4D les traduit en tant que zones de défilement indépendantes situées sur la même ligne.

5. Les onglets (de type tableau ou créés à l'aide de valeurs par défaut définies dans les Propriétés de l'objet) sont convertis sous forme de listes d'URL :

Si les valeurs sont des chaînes vides, 4D affiche 1, 2, 3... sur le navigateur.

6. Les zones de plug-ins sont publiables sur le Web, étant au préalable converties en HTML, en Image ou en "Image Map". Cette dernière solution permet de gérer les clics souris à l'intérieur de la zone de plug-in (par exemple, la zone _AP External clock de 4D_Pack est publiée en Image, le plug-in intégré 4D Chart est publié en Image Map). La manière dont une zone de plug-in incluse dans un formulaire est publiée sur le Web dépend des spécifications de l'éditeur du plug-in.

• Le mécanisme UserSet n'est pas supporté.

• Un mécanisme de sélection automatique de pages est fourni par 4D. Pour plus d'informations, reportez-vous à la description de la commande FIXER LIMITES AFFICHAGE WEB.

Lorsque vous développez une base 4D pour le Web, vous pouvez vous demander ce qui va se produire lorsque telle ou telle commande sera appelée. La commande produira-t-elle un effet sur la machine du serveur Web ou sur celle du navigateur Web ? Le process de connexion Web s'exécute sur la machine du serveur Web, mais l'interface utilisateur est affichée à distance sur le navigateur Web connecté. Par conséquent, pour le développement d'une base Web, les commandes 4D peuvent être classées de la manière suivante :

Les commandes qui ne sont pas affectées par leur exécution dans un process de connexion Web

Une commande telle que CREER ENREGISTREMENT fonctionne dans le process courant ; dans ce cas, elle crée un enregistrement depuis le process de connexion Web. Le même principe est valable pour les commandes telles que Largeur ecran, qui retourne la largeur de l'écran de la machine du serveur Web (la machine sur laquelle le process est exécuté).

Les commandes qui comportent des fonctionnalités intégrées supplémentaires pour le support transparent du Web

Les commandes à utiliser avec précaution

Les commandes suivantes s'exécutent localement sur la machine du serveur Web.

Par exemple, vous pouvez demander l'impression d'une sélection à partir du navigateur Web. Cependant, l'impression sera effectuée sur la machine du serveur Web.

De plus, lorsqu'un élément d'interface est appelé, il s'affiche sur la machine du serveur Web, par exemple Ouvrir document(""), par opposition à Ouvrir document("Ce document"). Vous devrez éviter ce genre d'appel car le navigateur Web attendra une réponse jusqu'à ce que la boîte de dialogue soit refermée sur la machine du serveur Web. En revanche, il est tout à fait possible d'appeler ces routines lorsqu'aucune boîte de dialogue n'est requise.

Les commandes qui ne sont pas supportées par les process de connexion Web

Encapsulation de HTML

Vous pouvez personnaliser le contenu des formulaires 4D convertis en HTML en encapsulant du code HTML (ou du Javascript) dans le formulaire. Le formulaire qui en résulte, côté navigateur Web, est la combinaison d'objets HTML et d'objets 4D.

Un objet texte statique de formulaire 4D contenant par exemple la chaîne "{page.HTM}", insère le document HTML "page.HTM" dans le formulaire 4D à l'endroit où se trouve l'objet texte.

Vous insérez un document dans son intégralité (en fait, tout ce qui est compris entre les balises <BODY> et </BODY>). Vous pouvez soit utiliser un document HTML existant, soit construire par le langage un document que vous sauvegardez sur disque et auquel vous vous référez par la suite.

Note : Dans certains cas, la conversion HTML de formulaires 4D créés en version 6.0.x contenant une référence à un document HTML ({mapage.htm}) peut ne pas donner le résultat escompté avec 4D version 6.7 et suivantes. Dans ce cas, il est possible de modifier le mode de conversion des formulaires à l'aide de la commande FIXER PARAMETRE BASE.

Toute variable texte 4D peut encapsuler du code HTML dans un formulaire 4D, si son premier caractère a le code 1 (par exemple, vtHTML:=Caractere(1)+"...Code HTML...").

Vous insérez ainsi des morceaux de code. Vous pouvez dans ce cas construire le code HTML en mémoire.

Pour assurer la maintenance du contexte de la base et le numéro d'identification du sous-contexte, 4D recalcule automatiquement les références de fichiers et les URLs.

Par exemple, toutes les références IMG et HREF des fichiers locaux sont recalculées. Si vous insérez votre propre code HTML dans un formulaire 4D avec une variable Texte, vous devez employer la syntaxe décrite plus bas.

Les fichiers locaux GIF sont par exemple recalculés en "/4DBin/_/GIF_file_pathname" où GIF_file_pathname est le nom de chemin complet en HTML vers un fichier GIF, compte tenu de la racine du volume où le fichier est situé.

Une petite méthode 4D comme celle qui suit retourne les références recalculées pour le nom de chemin d'accès reçu en paramètre :

      ` Méthode projet WWW Local GIF URL 
      ` WWW Local GIF URL ( Texte )
      ` WWW Local GIF URL ( Chemin d'accès natif ) -> URL vers fichier GIF local
   C_TEXTE($0;$1)
   $0:="/4DBin/_/"+HTML Pathname ($1)

Note : Reportez-vous aux exemples de la commande Mac vers ISO pour plus de détails sur la méthode HTML Pathname.

Ensuite, quand vous insérez le code HTML dans un formulaire 4D au moyen d'une variable Texte, vous pouvez écrire :

   vtHTML:=Caractere(1)+"<P><IMG SRC="+Caractere(34)+WWW Local GIF URL("F:.HTM"
                              +Caractere(34)+" ALIGN=MIDDLE></P>"+Caractere(13)

Cette méthode insèrera le document GIF dans le formulaire 4D à l'endroit où la variable 4D vtHTML est placée.

Important : Vous devez écrire ce type de code uniquement si vous insérez du code HTML dans un formulaire 4D. Si vous envoyez simplement une page HTML avec ENVOYER FICHIER HTML ou ENVOYER BLOB HTML, ou encore si vous utilisez une commande telle que AJOUTER ENREGISTREMENT, souvenez-vous que 4D effectue automatiquement la traduction et le recalcul pour vous.

Le recalcul ne change pas les liens pour les protocoles suivants :

• http:

• ftp:

• mailto:

• news:

• gopher:

• javascript:

• telnet:

• nntp:

• wais:

• prospero:

FIXER PARAMETRE BASE, Méthode base Sur authentification Web, Méthode base Sur connexion Web, Sécurité des connexions.