Nouvelles fonctionnalités OpenOffice.org Base 3.1
Contents
- 1 Nouvelles fonctionnalités de base de données dans OOo 3.1
- 2 Base Général
- 2.1 Macros dans les fichiers de base de données
- 2.2 Accès facilité aux documents formulaires/rapports par programmation
- 2.3 Nouveaux réglages de configuration pour les chemins des pilotes pré spécifiés
- 2.4 L'ébauche de relation est notifiée quand la structure de la base de données change
- 2.5 L'ébauche de relations supporte maintenant l'auto-référencement des relations des tables
- 3 Table
- 4 Requête
- 5 Formulaire
- 5.1 Contrôles de formulaire : Nouvelle propriété : "Direction du texte"
- 5.2 Contrôles de formulaire : Nouvelle propriété "Saisie requise"
- 5.3 Comportement de "Espace vide égale NULL" redéfini (refined)
- 5.4 Case à cocher : Propriété modifiée
- 5.5 Contrôles picto : Échelle de l'image en conservant les proportions
- 5.6 Contrôles picto : Images intégrées au document
- 5.7 Contrôles picto : Liés aux champs texte, interprétant leur contenu comme un lien relatif
- 5.8 Barre de navigation : Nouvelle icône "Contrôle de rafraîchissement"
- 6 Rapport
- 6.1 Nouveaux raccourcis pour Sun Report Builder
- 6.2 Liaison automatique de la première table à l'ouverture d'un nouveau rapport
- 6.3 Format de sortie de rapport maintenant également disponible dans la fenêtre des propriétés
- 6.4 La fenêtre Ajouter un champ prend en charge le tri et l'insertion dans une barre d'outils
- 6.5 Fonction Autopilot depuis SRB
Nouvelles fonctionnalités de base de données dans OOo 3.1
Compilé depuis les fonctionnalités de la liste de diffusion dba openoffice org et les applications référencés.
Base Général
Macros dans les fichiers de base de données
Les fichiers de base de données (.odb) permettent maintenant l'intégration de macros et de scripts, de la même manière que les autres types de documents.
Jusqu'à maintenant, les macros pouvaient être intégrées dans les sous-documents d'un document de base de données, c'est à dire les formulaires et rapports (qui techniquement sont des documents texte), elle n'auront dorénavant qu'un emplacement, le document de base de données.
Ce qui signifie que quand toutes les macros seront déplacées des formulaires dans la partie principale de la base de données, l'assignation de macros à des éléments d'un formulaire ne sera possible que depuis le document de base de données, et pas avec les macros du formulaire. Les macros peuvent être exécutées soit du document lui-même, ou de chacun de ses sous-composants : Formulaires, rapports, ébauche de table, ébauche de requête, ébauche de relation, vue. Une macro peut-être affectée à une barre d'outils, un menu, ou tout sous-composant. Lors de l'enregistrement d'une macro dans un formulaire ou un rapport, la boîte de dialogue finale qui vous permet de choisir ou stocker la macro ne listera plus les formulaires et rapports, mais le document de base de données.
Migration
Les documents de base de données créés avec des versions antérieures à Apache OpenOffice 3.1 peuvent contenir des formulaires ou rapports avec des macros ou scripts intégrés. Maintenant que c'est interdit, un chemin de migration est nécessaire.
Le but est de transformer les documents pour que tous les scripts et macros soient dans le fichier de base de données, et ceci ne peut-être réalisé automatiquement.
Précautions de compatibilité
Si l'utilisateur ouvre simplement un "vieux" document contenant des macros et/ou des scripts dans ses sous-documents, il n'aura qu'une boîte d'avertissement de compatibilité, à la première ouverture de ce fichier. Jusqu'à ce que l'utilisateur ait migré les macros, le document de base de données, et tous les sous-documents se comporteront comme si la fonctionnalité n'avait jamais été implémentée. En particulier, l'utilisateur est libre de créer des macros supplémentaires ou de modifier les macros existantes dans ses formulaires et rapports, de personnaliser les macros des sous-documents dans les menus et barres d'outils, de lier ces macros à des evénements dans les sous-documents, et ainsi de suite.
Assistant de migration
Ajout d'une nouvelle entrée de menu, appelée "Migrer les macros...", située dans la section supérieure du menu "Outils", immédiatement sous l'entrée "SQL..." existante.
Quand l'utilisateur sélectionne cette entrée de menu, un assistant le guide dans le processus de migration, qui suit concrètement les étapes suivantes :
- Fermer tous les sous-composants du document de base de données, formulaires, rapports, et tout autre objet en mode modification.
- Copie de sauvegarde du fichier de base de données
- Migration des scripts et des macros avec affichage d'une jauge de progression
- Affiche un sommaire
Pour une description détaillée de la fonctionnalité, vous ête encouragé à lire cette spécification :
http://wiki.services.openoffice.org/wiki/Macros_in_Database_Documents
Accès facilité aux documents formulaires/rapports par programmation
L'accès par programmation aux formulaires et rapports contenus dans les documents de base de données est plus facile qu'auparavant :
ThisDatabaseDocument.FormDocuments.getByName( "NomFormulaire" ).open
ThisDatabaseDocument.ReportDocuments.getByName( "NomRapport" ).open
Ouvrira le formulaire "NomFormulaire", ou le rapport "NomRapport", tout à fait de la même manière qu'un double clic sur le formulaire dans l'interface graphique le ferait, par exemple en appliquant les changement appropriés dans l'interface graphique.
Nouveaux réglages de configuration pour les chemins des pilotes pré spécifiés
(New configuration setting for pre-specifying per-driver classpaths)
Il y a un nouveau réglage dans le module de configuration org.openoffice.Office.DataAccess qui permet de spécifier, sur la base d'un pilote donné, un chemin de classe à utiliser lors de la recherche d'un pilote JDBC.
Un administrateur d'une installation partagée d'OOo peut utiliser ce réglage pour pré-configurer l'installation, sans que tous les utilisateurs aient besoin d'ajouter l'archive .JAR respective à leurs propres options Java.
Le chemin complet du nouveau noeud de configuration est
/org.openoffice.Office.DataAccess/JDBC/DriverClassPaths.
Un extrait d'exemple de configuration :
<node oor:name="JDBC">
<node oor:name="DriverClassPaths">
<node oor:name="com.mysql.jdbc.Driver" oor:op="replace">
<prop oor:name="Path">
<value>url_to_jar_file</value>
</prop>
</node>
</node>
</node>
L'ébauche de relation est notifiée quand la structure de la base de données change
L'ébauche de relation détecte maintenant quand une nouvelle table ou de nouvelles colonnes sont ajoutées. La boîte de dialogue "Ajouter une table" est également notifiée quand une nouvelle table a été ajoutée.
L'ébauche de relations supporte maintenant l'auto-référencement des relations des tables
La fenêtre d'ébauche de relation prend maintenant en charge la création de relations "réflexives", ou la table de référence est également la table référencée.
Table
Chemin relatif pour les bases de données fichiers
Jusqu'alors, quand vous créiez une base de données "fichiers" (comme le format dBase ou une feuille de calcul), l'URL des fichiers (appelons là "URL des données") était stocké de manière absolue - quelque chose comme "[../../../foo/bar file:///c:/foo/bar]".
Le résultat quand vous déplaciez le document de base de données (le fichier .odb) avec les données sur une autre machine, vous deviez soit dupliquer la structure de fichiers sur la machine cible, ou ajuster les réglages pour la base de données.
Il est maintenant possible que ce chemin soit stocké relativement en cochant l'option "Enregistrer les URL relatifs au système de fichier" accessible via "Outils > Options > Chargement/enregistrement > Général".
L'ébauche de table manipule la clé primaire différemment de hsqldb
Ceci concerne uniquement le mteur hsqldb.
Quand l'utilisateur ajoute une clé primaire auto-incrémentée cette dernière devient automatiquement la cle primaire de la table. Si l'utilisateur supprime après coup le drapeau de la clé primaire, le drapeau d'autoincrémentation sera également supprimé.
Hsqldb ne supporte qu'une seule colonne autoincrémentée qui doit donc être aussi l'unique colonne clé primaire.
PS: Une clé primaire peut consister en plus d'une colonne, ce qui n'est pas le cas pour hsqldb quand une colonne autoincrémentée est utilisée.
Les vues ouvertes pour édition sont automatiquement dans le mode "SQL direct"
Quand vous ouvrez une vue de table pour éditer sa commande SQL (fonctionnalité actuellement prise en charge seulement pour les bases HSQLDB intégrées), l'éditeur de requête passe automatiquement dans le mode "Exécution directe de commande SQL".
Requête
Paramètres reconnus dans les listes d'arguments de fonctions
Le parser d'OOo a la possibilité de reconnaître les paramètres dans les listes d'arguments de fonctions. Autrement dit, une requête comme :
SELECT CONCAT( :C, "nom" ) FROM "nom" présentera maintenant correctement la boîte de dialogue demandant à l'utilisateur la valeur du paramètre.
Édition de requête : Syntaxe SQL étendue
Le parser SQL reconnait maintenant la commande TRIM correctement.
Il prend également en charge
TRIM( FROM <NOM_COLONNE> )
comme une forme abrégée de
TRIM( BOTH FROM <NOM_COLONNE> )
Ces fonctions suppriment les blancs en tête et en fin d'une chaîne de caractères.
Surlignage de la syntaxe SQL
Prise en charge du surlignage de la syntaxe SQL pour les vues SQL dans Base, y compris la commande Outils > SQL...
La police utilisée pour la vue SQL respectera les mêmes réglages que pour le HTML et BASIC IDE ; toutes les couleurs utilisées peuvent être configurées.
Spécification:
http://wiki.services.openoffice.org/wiki/SQL_Syntax_Highlighting
Formulaire
Contrôles de formulaire : Nouvelle propriété : "Direction du texte"
Tous les contrôles de formulaires possèdent une nouvelle propriété "Direction du texte", qui... contrôle le sens du texte. Pour les langues écrivant de droite à gauche, Arabe, Hébreu, Hindou etc., les formulaires auraient l'air étrange s'ils devaient se plier à l'unique sens de gauche à droite.
Cette nouvelle propriété se trouve dans la boîte correspondante, onglet Général sous "Champ d'étiquette" si l'option "Activer pour les scripts complexes" est cochée dans Outils > Options > Paramètres linguistiques > Langue.
Voir les spécifications pour plus de détails :
http://specs.openoffice.org/g11n/Right-to-left_control_forms/R2L-enabled_control_forms.sxw
Contrôles de formulaire : Nouvelle propriété "Saisie requise"
Tous les contrôles de formulaire qui peuvent être attachés à une colonne de base de données (ayant la propriété "Champ de données") ont maintenant une nouvelle propriété appelée "Saisie requise". Elle se situe dans la fenêtre des propriétés, onglet Données, sous la propriété : "Espace vide égale NULL"
Cette propriété vérifie si oui ou non ce champ interdit les entrées vides (NULL). Elle est évaluée pour les contrôles qui sont liés à un champ de base de données défini comme requis (auquel il n'est pas permis d'avoir la valeur spéciale NULL), immédiatement avant que l'enregistrement en cours dans le formulaire ne soit enregistré dans la base de données.
Si la propriété est définie à "Oui", et que le champ ne contient aucune donnée quand l'enregistrement en cours est sur le point d'être enregistré, un message d'erreur est envoyé à l'utilisateur, et le contrôle concerné est sélectionné. Veuillez notez que ceci est le comportement reconnu pour l'instant – la valeur par défaut est "Oui" pour que les contrôles nouvellement créés se comportent comme ils l'auraient fait dans les versions précédentes de OOo.
Si la propriété est définie à "Non", et que le champ ne contient aucune donnée quand l'enregistrement en cours est sur le point d'être enregistré, il est tout simplement ignoré. C'est au moteur de base de données qu'il revient la charge de soit rejeter la mise à jour, ou de remplir la colonne respective avec une valeur par défaut coté serveur.
Si l'option "La saisie des données du formulaire vérifie les champs requis" n'est pas cochée dans les réglages avancés du document de base de données (Édition > Base de données > Paramètres avancés...), la propriété "Saisie requise" n'a aucun effet pour tous les contrôles de tous les formulaires dans le document de base de données, car ce réglage général prévaut sur les réglages individuels des contrôles.
Si le "Champ de données" n'est pas défini (si la propriété est vide), "Saisie requise" est désactivé, since it would be evaluated for bound controls only, anyway.
Si "Espace vide égale NULL" est défini à "Non", "Saisie requise" est également désactivé, car "Espace vide égale NULL" défini à "Non" signifie que quand l'utilisateur n'entre aucune valeur dans le contrôle, donc une chaîne vide, au lieu de la valeur dédiée NULL, est écrit (???), pour qu'il y ait toujours une valeur non NULL quelle que soit l'action de l'utilisateur. (then an empty string, instead of the dedicated value NULL, is written, so there's always a non-NULL value no matter the user's action.
Comportement de "Espace vide égale NULL" redéfini (refined)
Le comportement des contrôles de formulaire dont la propriété "Espace vide égale NULL" est définie à "Oui" a été redéfini. Ce changement devrait faire que les formulaires existants se comportent légèrement différement, mais sont certainement plus conformes à ce que l'on attend maintenant.
D'abord, la propriété est maintenant également respectée même si vous n'avez jamais touché le contrôle respectif avant de sauvegarder l'enregistrement. Ceci dit, imaginez un contrôle dont cette propriété est définie à "Oui", cette fois déclarant que si le contrôle contient une chaîne vide, et qu'alors cette valeur doit être propagée à le base de données comme la valeur (dédiée) NULL.
Formellement, quand vous vous placiez sur la ligne d'insertion du formulaire et que le contrôle était vide, que vous entriez des données dans d'autres contrôles de l'enregistrement courant, et sauvegardiez l'enregistrement sans jamais avoir touché au premier contrôle, il était actualisé comme une chaîne vide. Maintenant, avec le changement, il met à jour comme NULL, ainsi que l'option "Espace vide égale NULL" = "Oui" le requiert.
Deuxièmement, quand un contrôle était lié à une colonne de base de données qui était déclarée comme NOT NULL, le contrôle mettait toujours à jour une chaine vide au lieu de NULL, quelle que soit la valeur de "Espace vide égale NULL" demandée. Effectivement, ceci empechait les valeurs par défaut des champs de base de données coté serveur, puisque de telles valeurs par défaut sont appliquées seulement si le champ est NULL. Maintenant, avec le changement, le contrôle met toujours à jour NULL dans ce type d'installation, permettant de cette façon les valeurs par défaut coté serveur.
Case à cocher : Propriété modifiée
Les colonnes de case à cocher dans les contrôles de table ont maintenant la propriété "Statut triple", qui contrôle si oui ou non le statut "Indéterminé" est permit pour la case à cocher, comme c'est le cas pour les contrôles de formulaire case à cocher standards.
Contrôles picto : Échelle de l'image en conservant les proportions
Les contrôles de formulaire picto possèdent un mode supplémentaire pour mettre à l'échelle l'image qu'ils affichent.
Précédemment, vous pouviez contrôler les proportions en définissant la propriété "Échelle" à "Oui" ou "Non" seulement, où "Oui" impliquait une échelle anisotropique, c'est à dire qui distordait les dimensions de l'image.
Maintenant, la propriété "Échelle" permet les valeurs "Non" (même effet que précédemment), "Proportionnel" et "Adapter à la taille" (équivalent de l'ancien "Oui"). Quand "Proportionnel" est sélectionné, l'image est toujours mise à l'échelle pour "remplir" le contrôle, mais ses proportions sont conservées (but it's ratio is aspect kept constant.)
C'est particulièrement pratique pour les contrôles où le concepteur du document ne sait pas, au moment de créer le document/contrôle, les dimensions des images qui seront affichées. C'est notamment utile pour les contrôles d'image dans les formulaires de base de données, qui affichent des images provenant de la base de données.
Contrôles picto : Images intégrées au document
Les contrôles picto peuvent maintenant être liés à des images qui sont intégrées au document dans lequel le contrôle est placé.
Plus précisément, quand vous assignez une image à afficher à un contrôle picto, l'option "Lien" dans la boîte de sélection de fichier est maintenant activée.
Quand vous décochez l'option (par défaut cochée, pour le comportement "traditionnel"), l'image est affichée dans le contrôle, et lors de la sauvegarde du document, intégrée à ce dernier.
De cette façon, vous pouvez créer des documents avec des contrôles picto échangeables avec d'autres personnes/installations/plates-formes, ce qui avant était beaucoup plus difficile, car il fallait aussi copier les images, et les placer exactement au même endroit que sur la machine originale (ce qui était souvent simplement impossible).
Contrôles picto : Liés aux champs texte, interprétant leur contenu comme un lien relatif
(Titre original : Image controls: can be bound to text database columns, interpreting their content as relative link to the image)
Les contrôles picto dans les formulaires de base de données peuvent maintenant être liés aux colonnes texte. Auparavant, vous pouviez uniquement les intégrer à des colonnes dont le contenu pouvait raisonnablement être interprété comme binaire (BLOB etc.). Maintenant, quand vous sélectionnez une colonne texte de base de données comme source pour le contrôle picto, ce dernier interprétera le contenu de la colonne respective comme une URL, et chargera et affichera l'image pointée par cette URL. (L'adresse de) cette dernière peut également être relative au document contenant l'image intégrée. (Also, the URL might be relative to the document which the image control is embedded into.)
(Navigation Toolbar: new item "Refresh Control" )
Dans la barre de navigation du formulaire (celle utilisée dès qu'un formulaire ouvert est alimenté par une base de données), il y a une nouvelle icône, appelée "Contrôle de rafraîchissement", située à droite de l'icône "Actualiser".
Cette nouvelle icône est activée si et seulement si une zone de liste ou une zone combinée a le focus. Sur clic, rafraîchit la liste des éléments du contrôle.
C'est particulièrement intéressant pour des listes basées sur le contenu d'une table (ou requête) de la base de données, quand des instances extérieures au formulaire ont changé le contenu des données de la table/requête. Dans ce cas, vous pouvez actualiser/refléter ces changements dans la liste d'éléments du contrôle en utilisant ce bouton/cette fonction "Contrôle de rafraîchissement".
Rapport
Nouveaux raccourcis pour Sun Report Builder
Le menu Édition contient maintenant une entrée "Tout sélectionner"
NDT (temporaire) : Je continue de traduire mais n'ai pas trouvé l'entrée en tant que sous-menu... (En cliquant sur modifier, à partir d'un rapport créé avec SRB 1.0.x dans une base Hsqldb modifiée/créée sous 3.0.1, maintenant OOo 3.1 et SRB 1.1). Désolé, je ne peux donc vérifier les phrases suivantes. Merci de supprimer ce commentaire en couleur et corriger les erreurs si vous avez accès à ce sous-menu...
J'ai des problèmes de fonctionnement avec cette configuration, je fini néanmoins cette traduction, tente de déterminer si c'est ma configuration, s'il y a un contournement ou si cela doit faire l'objet d'une issue...
!!! Tout dans cette section reste donc à vérifier !!!
Merci de votre compréhension...
Contenant :
Édition > Tout sélectionner > Tout sélectionner (Ctrl-A) Sélectionner toutes les étiquettes Sélectionner tous les champs formatés Sélectionner le rapport
Liaison automatique de la première table à l'ouverture d'un nouveau rapport
(Automatic binding of first table when opening a new Report)
Lors de la création d'un nouveau rapport dans une base de données, ce rapport est lié à la première table de la base de données. De plus la boîte de dialogue Ajouter un champ s'ouvrira avec la liste des camps disponibles.
Format de sortie de rapport maintenant également disponible dans la fenêtre des propriétés
(Report output format now also available in the property browser)
La fenêtre des propriétés montre maintenant le format de sortie sélectionné pour un rapport dans l'onglet Données, dernière item sous Filtre, quand il est sélectionné dans SRB.
- Les formats actuellement disponibles sont
- ODF Document texte
- ODF Feuille de calcul (Spreadsheet )
La fenêtre Ajouter un champ prend en charge le tri et l'insertion dans une barre d'outils
(Add Field dialog supports sorting and insert toolbar)
La boîte de dialogue Ajouter un champ possède maintenant une barre d'outils au dessus de la liste des champs. Elle permet les tris croissant et décroissant, et un bouton Supprimer le flitre de tri qui annule le tri et restaure l'ordre d'origine de la source (Table, requête). De plus cette barre d'outils contient un bouton Insérer permettant d'insérer le ou les champs dans une section d'un rapport. La sélection multiple est (donc) également prise en charge.
Fonction Autopilot depuis SRB
(Function Autopilot from inside the SRB)
La fonction Autopilot utilisée dans les feuilles de calcul est maintenant disponible dans Sun Report Builder.
L'Autopilot peut être démarré depuis :
- Le champ de données (champ formaté et contrôle picto)
- L'expression d'impression conditionnelle (Imprimer les valeurs répétées ?), dans l'onglet Général
- La formule
- La valeur initiale
L'Autopilot montre toutes les fonctions prises en charge par le moteur de rapport.
La documentation de Sun Report Buider est ici : (The documentation for the SRB can be found here:)
http://wiki.services.openoffice.org/wiki/SUN_Report_Builder/Documentation
Une description des fonctions est disponible ici : (The functions description can be found here:)
http://wiki.services.openoffice.org/wiki/Base/Reports/Functions