L'équipe de développement d'extensions VS Code recherche des bêta-testeurs pour fournir des commentaires sur une refonte proposée du flux de travail d'édition côté client. La liste complète des modifications se trouve dans la description de la GitHub pull request. Voici les points saillants :

• Prend en charge l'utilisation de l'édition côté client dans n'importe quel dossier d'espace de travail non-isfs, pas seulement dans les dossiers de votre système de fichiers local. Par exemple, avec le développement à distance VS Code.
• Créez un index de toutes les classes, routines MAC et INT et incluez les fichiers dans les dossiers d'espace de travail non-isfs. Cela sera utilisé pour déterminer l'URI des classes et des routines (par exemple, pour Aller à la définition). Lorsque le dernier fichier associé à une classe ou une routine donnée est supprimé, la classe ou la routine sera supprimée sur le serveur.
• Affichez et masquez automatiquement les vues InterSystems Explorer et Projects Explorer en fonction des dossiers de l'espace de travail. InterSystems Explorer n'est affiché que s'il existe au moins un dossier d'espace de travail non-isfs. Projects Explorer n'est affiché que s'il existe au moins un dossier isfs. Cela remplace le paramètre objectscript.showExplorer.
• Modifiez la valeur par défaut du paramètre objectscript.explorer.alwaysShowServerCopy sur true. InterSystems Explorer doit toujours afficher la copie du serveur, car la copie locale peut être ouverte à partir de l'explorateur de fichiers.
• Mettez en cache la liste des extensions de documents abstraits Studio prises en charge pour chaque connexion au serveur afin que nous puissions les importer correctement à partir des dossiers côté client. L'importation de documents abstraits est désormais indépendante des paramètres objectscript.export, à l'exception des DFI qui vérifient toujours les paramètres d'exportation pour préserver le comportement actuel de division de chemin. Tout fichier dans un dossier d'espace de travail qui a une extension de document abstrait prise en charge sera importé avec la dernière partie du chemin utilisée comme nom de serveur (à l'exception des DFI qui correspondent aux paramètres d'exportation).

En plus des commentaires généraux sur les modifications, quatre questions de conception restent encore sans réponse :

1. Est-ce que des utilisateurs souhaitent que InterSystems Explorer (PAS l'explorateur de fichiers VS Code par défaut) affiche les copies locales des documents ? Si ce n'est pas le cas, le paramètre objectscript.explorer.alwaysShowServerCopy peut être supprimé.
2. Certains utilisateurs modifient-ils les fichiers DFI localement et ont-ils des référentiels qui dépendent du comportement de division des dossiers ? Si ce n'est pas le cas, cette gestion spéciale sera supprimée et les DFI seront traités comme tout autre type de document abstrait.
3. La suppression automatique des fichiers sur le serveur lorsque la copie locale est supprimée doit-elle être protégée par un paramètre afin que les utilisateurs puissent la désactiver ?
4. Cette extension dispose d'une fonctionnalité qui tentera d'ajuster le nom d'une classe ou d'une routine lorsqu'elle est copiée ou déplacée vers un nouvel emplacement dans le dossier de l'espace de travail. Cela a été implémenté pour aider les développeurs à synchroniser le chemin d'accès au fichier et le nom du document. Il peut être désactivé à l'aide du paramètre objectscript.autoAdjustName. Les utilisateurs apprécient-ils cette fonctionnalité ? Le paramètre objectscript.autoAdjustName doit-il être défini sur false par défaut ? Cette fonctionnalité doit-elle être entièrement supprimée puisque l'index du document supprime la nécessité que le chemin corresponde au nom du document ?

Voici comment vous pouvez partager vos commentaires :

1. Téléchargez le fichier zip à la fin de cet article et extrayez le fichier vsix qu'il contient.
2. Installez le fichier vsix dans VS Code en suivant ces instructions ou en faisant glisser le fichier depuis votre explorateur de fichiers vers la vue Extensions dans VS Code.
3. Suivez votre flux de travail de développement normal et essayez de nouvelles fonctionnalités.
4. Partagez votre expérience ici ou sur la GitHub pull request.

Merci d'avance d'avoir essayé cela et nous espérons que vous aimerez les changements !

vscode-objectscript-2.12.8-dev.1401.vsix_1.zip