Français
  • A propos du composant BSPK
  • ATL
  • BWEB
  • Historique des versions
  • FAQ

    • 4D dans BWEB

    Cette page regroupe les pièges propres au rendu des pages et au code du composant. Les pièges du langage lui-même sont sur la page Le langage 4D.

    Dans les balises 4D

    On ne peut pas appeler une méthode depuis #4DIF ou #4DEVAL. La balise est recrachée en texte brut au lieu d'être évaluée. Calculez d'abord la valeur dans un bloc #4DCODE, puis testez la variable. Le court-circuit du || masque souvent le défaut sur le site public : il n'apparaît alors que sur les écrans /bweb/*.

    Une erreur dans un #4DCODE rend le bloc entièrement vide, sans aucun message nulle part. Quand un bloc disparaît sans explication, placez une trace en tête du code et resserrez : l'échec est à l'intérieur, pas dans la configuration du bloc.

    cs n'existe pas dans PROCESS 4D TAGS. Passez par ds.MyDataClass.render() ou par un autre point d'entrée de dataclass.

    Le nombre de PROCESS 4D TAGS par bloc est limité. Un très gros bloc cesse, sans rien dire, de traiter les balises à mi-parcours.

    Composant et hôte

    Depuis le composant, adressez les tables de l'hôte par ds["TABLE"], jamais par ds.TABLE. Les tables de l'hôte n'existent pas au moment où le composant est compilé : la forme avec un point échoue donc à la compilation, et un Try ne protège pas d'une erreur de compilation. Utilisez une référence non typée.

    Les variables process ne sont pas partagées entre l'hôte et le composant. Une variable posée côté composant est invisible depuis l'hôte : c'est le rôle de BSPH_SET_PROCESS_VAR.

    Pour les tables de l'hôte, la classe d'entité active est celle de l'hôte (Project/Sources/Classes). Les copies placées sous Resources/Misc/DataClasses dans le composant sont des gabarits d'installation, pas du code en fonctionnement : les modifier ne change rien tant qu'une installation ne les rejoue pas.

    Le code personnalisé se place en dehors des balises START BSPK / END BSPK. Tout ce qui est à l'intérieur est régénéré. Ne modifiez jamais les classes BSPK_* elles-mêmes.

    Le dev-panel tourne dans un Shadow DOM

    Depuis que le panneau a été placé dans un shadow root, trois habitudes ne fonctionnent plus :

    • les variables globales implicites sont mortes — une fonction déclarée dans un script du panneau n'est pas visible depuis un autre ; exportez-la explicitement ;
    • les attributs event-onClick du balisage ne se déclenchent pas — les écouteurs doivent être attachés à l'intérieur du shadow root ;
    • document.querySelector n'atteint pas les nœuds du panneau, et, à l'inverse, le panneau porte ses propres attributs data-uuid. Un sélecteur destiné aux blocs de la page, s'il n'est pas restreint, trouvera aussi des nœuds du panneau — ce qui a déjà supprimé le mauvais élément.

    Mettez les sélecteurs data-uuid entre guillemets en échappant la valeur, et restreignez-les toujours à la zone voulue. Le détail est sur la page Le dev-panel.

    Diagnostiquer une page entière qui tombe

    Une page qui s'affiche comme la page 404 « Wakanda » sur toutes les URL, y compris /_claude/ping, n'est pas un problème de routage : cela signifie que BSPK_WEB_ON_CONNECTION ne compile pas. bspk.log reste vide. Comparez l'équilibre des If / End if avec la version de git HEAD.

    Un bloc isolé qui fait tomber le rendu se désigne lui-même : le toast de développement indique le bloc, son uuid et l'erreur.

    Gabarits et caches

    Un .html sous Resources/bweb/bspk/ reste inerte jusqu'à BSPK_REFRESH_STORAGE : les gabarits sont mis en cache dans Storage. Le JavaScript, lui, est servi directement depuis le disque.

    Un résultat de rendu peut être mis en cache dans la session. Une formule de colonne ou un affichage conditionnel modifiés peuvent continuer d'afficher l'ancien résultat : F5 et un rechargement ne suffisent pas, il faut se déconnecter puis se reconnecter.

    Piège : ce cache de session fait passer un code correct pour un code cassé.

    Voir aussi