Sauvegarde du code source du projet sans jetons

Les commandes, constantes, tables et champs sont stockés avec leurs tokens dans les fichiers de code source du projet (fichiers 4dm). Cela permet à 4D de les renommer automatiquement. Mais parfois, vous souhaitez que ces fichiers de code source soient stockés sans tokens pour une meilleure lisibilité avec un système de contrôle de version ou un éditeur de code externe, ou pour un meilleur partage du code entre les projets. Voyons comment faire pour que 4D stocke le code source sans ces jetons.

Que sont les tokens ?

Ce système permet à 4D de reconnaître automatiquement une commande, une constante, une table ou un champ dans l’ancien langage, même si ces éléments ont été renommés.
Un nom de commande est suivi de « :C » et de l’ID de la commande, une constante de « :K » et de l’ID de la constante, une table de  » : » et de l’ID de la table, un champ de  » : » et de l’ID du champ.

Lors de l’ouverture du code source dans l’éditeur de méthode, 4D renomme automatiquement les éléments en fonction de leurs tokens. Ces tokens sont cachés par 4D dans l’éditeur de méthodes, mais si vous utilisez un éditeur de code source externe, ils sont visibles.
La lecture du code source peut être plus difficile dans un éditeur de code source externe ou dans un système de contrôle de version à cause de ces jetons.

Exemple d’une méthode avec des tokens :

Comment les désactiver ?

Pour faciliter la lecture, 4D vous offre désormais la possibilité de stocker les fichiers de code source sans tokens.
Vous avez à votre disposition une nouvelle préférence 4D pour que vos nouveaux projets écrivent les fichiers de code source sans tokens.

Par défaut, l’option est activée pour qu’il n’y ait aucun changement : votre code source est toujours enregistré avec des tokens. Mais si vous désactivez l’option, les fichiers de code source de vos nouveaux projets seront enregistrés sans tokens.

Exemple de la même méthode sans tokens :

Qu’en est-il de mon projet existant ?

Lorsque vous désactivez la préférence 4D tokenization, le fichier 4DProject des nouveaux projets contient un attribut booléen nommé « tokenizedText » réglé sur *false*.
Techniquement, vous pouvez ajouter cet attribut au fichier 4DProject d’un projet existant, mais il ne supprimera pas les tokens dans les fichiers de code source existants jusqu’à ce qu’ils soient à nouveau sauvegardés par une modification dans l’éditeur de méthode 4D ou en utilisant la commande METHOD SET CODE ou en utilisant la commande Notez que cet attribut est utilisable depuis 4D v19 LTS.

Comment fonctionne-t-il ?

Vous savez peut-être que dans un projet, tout votre code source est enregistré en anglais dans les fichiers 4DM, même si vous développez en langue française.
Lorsque l’éditeur de méthodes 4D ouvre un fichier 4DM, les tokens sont d’abord pris en compte. Ensuite, les commandes, constantes, tables et champs sont reconnus par leur texte (et traduits si vous développez avec la langue française). Ainsi, même si votre code source est stocké sans token, il reste éditable comme d’habitude dans l’éditeur de méthodes 4D !

N’oubliez pas que si vous désactivez la tokénisation, vous devrez effectuer vous-même le renommage des commandes/constantes/tables/champs dans le langage existant, comme c’est l’usage avec les autres plateformes de développement.

Projet de framework

Si vous développez un projet cadre destiné à être partagé avec d’autres projets, vous pouvez rencontrer des problèmes concernant les tables et les champs avec le code existant. Vous ne pouvez pas vous limiter à copier les fichiers du framework vers le projet s’il contient des tables qui n’ont pas les mêmes ID. Par exemple, la table [Setting] de votre framework peut être #1, mais #3 dans un projet cible. Si les fichiers de code source copiés du framework contiennent des jetons, 4D remplacera la table [Setting] par celle ayant l’ID #1 dans le projet cible !

Afin de faciliter le partage du code source, vous pouvez désactiver la sauvegarde des jetons dans votre projet de framework. Ensuite, après avoir copié les fichiers du framework dans le projet cible, il reconnaîtra la table [Setting] par son nom et non par son ID (potentiellement erroné) !