Cette rubrique présente les nouvelles fonctions de la version 8.5.1.
Les sections se présentent comme suit :
Rich UI
Par défaut, les projets de système Rich UI
suivants sont utilisés :
- Pour les widgets EGL non basés sur Dojo : com.ibm.egl.rui_4.0.1.1
- Pour les widgets Dojo EGL : com.ibm.egl.rui.dojo.widgets_2.1.0.1
- Pour les échantillons Dojo EGL : com.ibm.egl.rui.dojo.samples_2.1.0.1
- Pour l'accès à l'environnement d'exécution Dojo local : com.ibm.egl.rui.dojo.runtime.local_1.6.1
Les projets suivants prennent en charge l'utilisation de CDN (Content
Delivery Network) pour Dojo 1.6.1 :
- Accès à l'environnement d'exécution Dojo Google : com.ibm.egl.rui.dojo.runtime.google_1.6.1
- Accès à l'environnement d'exécution Dojo AOL : com.ibm.egl.rui.dojo.runtime.aol_1.6.0
Les informations de configuration suivantes sont disponibles :
- Pour des instructions sur l'importation de projets du système Rich UI, voir Importation de projets fournis par le produit.
- Si vous migrez vers un nouveau projet d'exécution Dojo
à partir de l'un de vos projets Rich UI existants, vous devez mettre à niveau le chemin de compilation EGL
dans votre projet. Pour plus de détails, reportez-vous à la section relative à la présentation des tâches de mise à niveau de widget : Présentation d'EGL Rich UI.
Voici les nouvelles fonctionnalités :
- Si vous êtes confronté à des fuites de mémoire, vous pouvez utiliser la fonction UtilLib.destroyRUIHandler pour demander la suppression des widgets dans un gestionnaire, dans les gestionnaires imbriqués dans ce dernier et dans les gestionnaires imbriqués dans ces derniers, à n'importe quel niveau de profondeur. Pour les détails, voir Gestion de mémoire Rich UI.
La version 8.5.1 ne prend pas en charge le développement Rich UI sur une plateforme Linux 64 bits. Cela est dû à des restrictions au niveau du logiciel externe.
Traitement Java
Le code Java™ natif et généré peut maintenant partager des connexions de base de données, ce qui permet de valider les modifications qui ont été apportées précédemment à la base de données dans une unité d'exécution, même si cette dernière contient deux types de code. Pour plus de détails, voir SharedResourcePowerServer et JavaLib.getSharedResourcePowerServer.
De plus, vous pouvez spécifier le codage de caractères utilisé lors de l'accès à un fichier qui est lié à un enregistrement CSV EGL. Cette technique comprend la définition de la propriété conversionTable lorsque vous créez une association de ressources. Pour les détails, voir Eléments d'association.
Pour une présentation du support des enregistrements CSV, voir Stéréotype CSVRecord.
Définition de nouvelles préférences pour le débogueur EGL
Deux nouvelles préférences sont disponibles lorsque vous cliquez sur , puis que vous développez
EGL et que vous cliquez sur
Déboguer :
- Eviter l'arrêt dans un composant si son code source est indisponible (étape omise automatiquement)
Indiquez comment le débogueur va répondre s'il accède à un composant dans un fichier EGLAR, si le code source n'est pas disponible.
- Eviter l'invite pour les programmes de même nom en accédant au premier programme trouvé dans le chemin de génération EGL
Indiquez comment le débogueur va répondre s'il accède à un programme lorsque plusieurs programme portent le même nom dans votre chemin de génération ou espace de travail EGL.
Pour les détails, voir Définition des préférences du débogueur EGL.
Réduction du temps de traitement lors d'une génération automatique
Vous pouvez appeler un script Ant pour nettoyer un espace de travail et déclencher une génération automatique. Dans ce cas, vous pouvez utiliser l'argument Java Java Virtual Machine nommé egl.build.gen.debug afin d'indiquer si la sortie générée inclut les informations de débogage. La valeur par défaut de cet argument est true, mais vous pouvez définir cette valeur sur false si vous souhaitez réduire le temps de traitement.
Pour les détails, voir Génération avec un script Ant.