Publiée dans 4D v18, l’architecture projet est une évolution importante pour les bases de données 4D. Un projet est composé de fichiers texte lisibles et permet à votre code 4D de bénéficier de la puissance des outils de contrôle de version. De plus, l'architecture projet prend en charge de manière native les bibliothèques et les interfaces les plus modernes.

Pour plus d'informations sur les projets, veuillez consulter developer.4D.com.

Vous pouvez convertir en projet une base de données binaire 4D (fichier .4db) à l’aide d’une simple commande de menu de votre application 4D monoposte. Etant donné que l'export ne crée qu'une nouvelle version de la base de données existante, les fichiers d'origine demeurent inchangés. Ainsi, vous pouvez convertir votre base de données autant de fois que nécessaire jusqu'à ce que vous soyez satisfait du résultat. Ouvrez votre base de données .4db, apportez des modifications, puis reconvertissez-la et testez les résultats. Chaque nouvelle conversion remplace la précédente.

N'oubliez pas qu'un export est une opération à sens unique :

• une fois qu'une base de données 4D a été exportée en tant que projet, les deux versions deviennent indépendantes l'une de l'autre.
• un projet ne peut pas être exporté dans un fichier .4db
• dans la mesure où les projets utilisent les technologies les plus modernes, ils ne prennent pas en charge certaines anciennes fonctionnalités. Ces fonctionnalités sont mises à jour automatiquement si possible ou génèrent des erreurs de conversion (voir ci-dessous).

Lorsque vous convertissez une base de données 4D existante en projet, le fichier .4db reste inchangé : un dossier nommé "Project" est créé à côté de votre fichier .4db et contient tous les fichiers nécessaires.

Note : Si un dossier nommé "Project" existe déjà au même niveau que votre fichier .4db (par exemple, si une conversion a déjà été effectuée), il sera remplacé par le processus de conversion.

Pour convertir une base de données en projet :

1. Ouvrez la base de données à convertir.
2. Sélectionnez Fichier > Exporter > Structure vers projet.

   

Notes:

• Cet élément de menu est disponible uniquement sur un 4D monoposte.
• Cet élément de menu est disponible uniquement si une base de données binaire est ouverte -- elle est désactivée dans les bases projet.
• Voir également la commande Exporter fichier structure.

Si la conversion est réussie et qu’aucune erreur n’est générée, la boîte de dialogue suivante s’affiche :

• Afficher l'historique : met en évidence le fichier d'historique de conversion sur votre disque. La lecture de ce fichier est fortement recommandée car le processus de conversion pourrait avoir modifié certaines parties de l’application (voir la section Vérification de la conversion ci-dessous).
• Ouvrir projet : redémarre l'application 4D et charge le projet converti.

Le fichier de données n'est pas impacté par la conversion, il demeure inchangé. Seuls les éléments de développement sont convertis. Vous pouvez toujours ouvrir le fichier de données avec le fichier de structure .4db après une conversion.

De plus, les dossiers Resources, Logs ou Web de .4db sont automatiquement utilisés par le projet, sans aucune modification. Cela facilite la conversion et les tests de votre projet.

Au cours de la conversion, un nouveau dossier "Project" est créé au même niveau que votre fichier de structure .4db. Il contient tous les développements de votre application sous forme de fichiers texte : formulaires, structure, méthodes, triggers, menus, aides, listes. Il contient également un fichier .4DProject, qui est le fichier principal de votre projet converti 4D :

Lorsque vous ouvrez le fichier .4DProject avec votre application 4D, le projet utilise le même dossier de ressources et le même dossier Web que le fichier .4db existant, ce qui vous permet de tester facilement le projet.

Vous pouvez toujours ouvrir la base de données .4db, apporter des modifications si nécessaire (voir ci-dessous), puis l'exporter à nouveau et la tester. Vous pouvez répéter cette opération jusqu'à ce que vous soyez satisfait de la conversion.

Un fichier journal au format JSON est créé par défaut pendant le processus de conversion pour référencer tous les problèmes nécessitant une action du convertisseur. Dans ce fichier, les messages sont classés en trois catégories (propriété "severity"), par exemple:

• info : décrit une action nécessaire exécutée automatiquement par le convertisseur et qui n'aura aucun impact sur l'interface ou les fonctionnalités de l'application. Par exemple, si vous avez des images dans la bibliothèque d'images, 4D les exporte dans le dossier Resources de la base de données (voir exemple ci-dessus).

• warning : décrit une action nécessaire exécutée automatiquement par le convertisseur qui pourrait entraîner des différences dans les fonctionnalités ou l'interface de l'application, sans toutefois empêcher la base de données de s'exécuter. Les avertissements exigent généralement que vous contrôliez l'impact de la conversion sur votre code. Par exemple, des avertissements sont retournés lorsque des paramètres de compatibilité non pris en charge, tels que "Mode Unicode" ou "Boutons radio regroupés par nom" sont automatiquement activés.

• error : décrit un problème qui nécessite votre intervention pour être réglé. Cela peut empêcher la base de données de fonctionner correctement. Par exemple, d'anciens objets de formulaire ne sont plus pris en charge, tels que les boutons inversés. Dans ce cas, vous devez convertir le bouton vous-même en un bouton 3D dans le fichier .4db avant de relancer l'opération de conversion.

Lorsque des modifications sont requises dans la base de données .4db, modifiez simplement le code ou le formulaire en conséquence et exportez à nouveau la structure. Répétez l'opération autant de fois que nécessaire jusqu'à ce que vous soyez satisfait du résultat.

Lors de la conversion, d'anciennes technologies 4D sont converties en implémentations plus modernes, tandis que d'autres sont modifiées ou ignorées. En particulier :

• La bibliothèque d'images n'existe plus dans les projets. Lors de la conversion, 4D exporte toutes vos images dans le dossier Resources de la base de données.
• Les objets de formulaire et les propriétés d'objet de formulaire ont été mis à jour (ils utilisent maintenant la même grammaire que Formulaires dynamiques). Les parties obsolètes ne sont pas prises en charge.
• Les sous-tables (obsolètes depuis 4D v11, voir ) ne sont pas prises en charge dans les projets.
• Les groupes imbriqués d'objets formulaire ne sont pas pris en charge dans les projets (les groupes ne sont implémentés que sur un seul niveau d'objets). Pendant la conversion, les groupes imbriqués sont extraits jusqu'au plus bas niveau.
• La propriété Saisissable n'est pas prise en charge par les projets car l'ordre de saisie est géré par la collection entryOrder dans Formulaires dynamiques. Durant la conversion, la collection est automatiquement complétée en fonction de la configuration existante de l'ordre de saisie (le plan des objets et les propriétés saisissables). Vous pouvez vérifier dans la base projet si l'ordre de saisie des formulaires a été converti correctement.
• Les paramètres de compatibilité de la base sont tous réinitialisés comme pour une nouvelle base de données. Consultez le fichier journal de conversion pour vérifier l'état des paramètres de compatibilité de votre base de données.
• Toutes les options de compatibilité des formulaires (ex : "Ajustement dynamique", "Avec contraintes") sont réinitialisées, comme un nouveau formulaire.
• Les feuilles de style sont exportées sous forme de feuilles de style CSS dans des fichiers JSON stockés dans le dossier "/SOURCES" nommé:
  • "styleSheets_mac.css" sous macOS,
  • "styleSheets_windows.css" sous Windows.

Les feuilles de style appliquées sont ajoutées en tant qu'attributs "class" pour former des descriptions d'objet JSON.

• Les objets de formulaire s'étendent automatiquement vers le bas lorsque la taille de la police CSS ou de la plate-forme est trop grande. Cela empêche le texte d'être tronqué.
• La visibilité des marqueurs de contrôle de sortie n'est pas préservée lorsque vous fermez et réouvrez les formulaires dans les projets.
• Les commentaires de l'explorateur sont exportés sous forme de fichiers de documentation markdown (texte brut). Pour plus d'informations sur ces fichiers, veuillez consulter developer.4d.com.

Les propriétés et objets de formulaire suivants ne sont pas compatibles avec les exigences des interfaces modernes et sont désormais obsolètes. Ils ne sont pas pris en charge dans les Formulaires dynamiques, et pourront être signalés dans le fichier d'historique de conversion en projet (cf. commentaires).  

Le rendu des objets formulaire peut être différent dans les projets lorsque vous utilisez des commandes de formatage avec des paramètres par défaut ou des paramètres manquants.

Les options de structure de la base de données 4D suivantes sont obsolètes et seront modifiées ou généreront des erreurs dans le fichier d'historique de conversion du projet (voir commentaires).  

Les éditeurs et fonctionnalités suivants de la Boîte à outils sont obsolètes et ne sont pas pris en charge dans les projets.

Lors de la conversion, les utilisateurs et groupes 4D existants sont automatiquement extraits du fichier .4db et stockés dans le fichier directory.json du projet.

Dans les projets, le code étant stocké dans des fichiers texte ouverts, la gestion des accès utilisateur de 4D ne fonctionne pas de la même manière que dans les bases de données binaires. En particulier:

• En mode monoposte, le système de mot de passe est toujours désactivé:
  • la boîte de dialogue de connexion n'est jamais affichée,
  • l'utilisateur courant est toujours le Super_Utilisateur,
  • les paramètres du serveur SQL ou du serveur Web sont ignorés (mais peuvent être définis pour le déploiement client / serveur).
• Il n'y a pas de différence entre les utilisateurs créés par le Super_Utilisateur ou l'administrateur.
• Il n'est pas possible d'affecter un groupe d'accès ou un groupe propriétaire à des menus, des méthodes et des formulaires. La protection du code doit être gérée au niveau de l’outil de contrôle de version.
• Les identifiants d’utilisateur et de groupe (références) sont gérés de manière dynamique pendant la session, mais ils ne sont pas stockés.

   

En mode client-serveur, le contrôle d'accès utilisateur fonctionne dans les bases projet comme dans les bases binaires. Toutefois, l'affectation de groupes aux menus, méthodes et formulaires n'est pas prise en charge (voir la note de sécurité).

Par conséquent, après conversion : 

• Le type d'utilisateur "Développeur" n'existe plus, tous les utilisateurs (à l'exception du Super_Utilisateuret de l'Administrateur) ont le type "Utilisateur".
• Le type groupe et les propriétaires de groupe sont supprimés.
• Les identifiants utilisateur et de groupe statiques ne sont pas conservés, à l'exception du Super Utilisateur (ID = 1) et de l'Administrateur (ID = 2).
• Dans le journal de la base, l'information "user4D_id" est remplacée par "user4D_alias" qui est l'alias utilisateur de 4D (nom d'utilisateur 4D si aucun alias n'a été défini).

Notes de sécurité : 

• Les bases de données de projet ne prenant pas en charge l'affectation de groupe à des méthodes (ni à des menus et des formulaires), elles ne permettent pas de contrôler les urls 4DACTION/ ni 4D Write Pro/4D View Pro via l'accès utilisateur 4D. Si votre base de données utilisait ce type de contrôle, vous devez utiliser la méthode base Sur connexion Web ou l'attribut «Disponible via les balises HTML 4D et URLS (4DACTION ...)» pour les méthodes, et la commande FIXER METHODES AUTORISEES pour les formules.

• Lorsque vous créez une application projet client-serveur qui contrôle l'accès par le biais d'utilisateurs et de groupes, veillez à copier le fichier directory.json dans le dossier Settings du dossier data afin qu'il soit disponible pour l'application serveur résultante. 

Les bibliothèques d'objets personnalisées existantes (.4il sous Windows ou .4dlibrary sous macOS) doivent être exportées séparément si vous souhaitez les utiliser dans vos projets. Pour plus d'informations, veuillez vous référer à cet article de blog.

La stratégie de déploiement de projets 4D est basée sur des fichiers compressés .4dz, où toute la structure est en lecture seule. C'est le cas des applications fusionnées, ou des composants compilés. Par conséquent, les commandes qui modifient la structure ne fonctionneront pas et ne doivent pas être utilisées dans les applications déployées. Si elle sont appelées, elles ne feront rien ou généreront une erreur, selon le contexte.

Gardez à l'esprit que la modification des fichiers de structure dans les applications déployées n'est pas recommandée pour les raisons suivantes :

• elle empêche l'installation d'applications fusionnées dans des dossiers Applications classiques, sur lesquels les utilisateurs n'ont parfois pas de droits d'accès en écriture
• elle rompt la signature des applications signées, auquel cas le système d'exploitation peut considérer qu'elles ont été infectées
• elle rend la mise à jour des versions de structures déployées très complexe lorsque des modifications locales doivent être sauvegardées.

Cependant, si vous devez absolument éviter le format .4dz et conserver votre dossier "Projet" tel quel, afin de pouvoir modifier ses fichiers sources sur les sites déployés (ce qui n'est pas recommandé, comme expliqué plus haut), vous pourriez être intéressé par la clé PackProject.

Voici la liste des commandes qui modifient la structure :

Lorsqu'une base de données est convertie en projet, le compteur d'archives de sauvegarde est réinitialisé. Cela signifie que le premier fichier d'archive de sauvegarde dans un projet converti sera nommé maBase-0001, quel que soit le numéro de séquence du dernier fichier d'archive dans la base de données binaire.

En fait, le compteur d'archives de sauvegarde est lié au fichier de structure de la base de données. Lorsque vous renommez ou déplacez un fichier .4DB, et encore plus lorsque vous le convertissez en .4DProject, un nouveau compteur de sauvegarde est lancé.

Une fois que vous êtes satisfait de votre base de données convertie et que vous souhaitez commencer à travailler sur votre projet, vous pouvez nettoyer votre répertoire de travail :

1. Supprimez vos fichiers .4db et .4dindy du dossier de l’application (par exemple, déplacez-les dans un répertoire de sauvegarde). Sous macOS, vous devrez peut-être utiliser la commande Afficher le package au préalable ou supprimer l'extension .4dbase (voir ci-dessous). 
2. Sur macOS, supprimez l’extension de dossier .4dbase pendant toute la phase de développement. Puisque vous allez travailler avec des fichiers texte et les placer sous un outil de contrôle de version, vous devez y avoir un accès direct. 

Si vous souhaitez que le fichier de données soit ouvert automatiquement une fois que le projet est déplacé vers d'autres machines, vous pouvez le rendre conforme à l'architecture du projet, comme décrit sur developer.4d.com:

1. Renommez votre fichier de données "data.4dd".
2. Créez un dossier nommé "Data" et déplacez le fichier data.4dd dans ce dossier
3. Stockez le dossier Data au même niveau que le dossier Project.