OK
Contact
 +237 22 65 80 36
 info@serenix-ws.com
Composants XML
XML est à ce jour indispensable dans l’ingénierie logicielle à tous les niveaux tant pour l’accès aux données que pour la présentation (interface graphique). SereniX Worlwide Solutions entend fournir à tous ses clients des solutions hautement paramétrables et adaptables à chaque client sans recourir aux modifications des codes sources. C’est d’abord pour couvrir un besoin interne que les composants suivants ont été développés :
  • DTD Parser: Développé avec le langage JAVA, il permet de vérifier si une DTD est bien écrite et si tous les éléments référencés dans la DTD sont définis.
  • DTD Builder: Cet outil permet de créer graphiquement les DTD.
DTDParser est conçu et réalisé entièrement par KAMGA Marc Olivier pour ses besoins propres parce qu'il n' était pas évident de trouver un parser qui lui donne entièrement satisfaction. Même lorsqu'on sera rendu à une version plus complète, nous n'avons pas la prétention de pouvoir satisfaire entièrement tout le monde.
Lors de l'éxécution en ligne de commande via le jar, c'est la classe MainDTDParser qui est exécutée. Elle fait appel à la classe DTDParser qui est la classe qui effectue véritablement le parsing de la DTD. Le parsing se fait en invoquant l'une des méthodes suivantes de la classe DTDParser :
  • parse(<Nom de fichier>) : pour les fichiers en local
  • parse(<url>) : pour les fichiers se trouvant sur le réseau et accessibles via URL
  • parse(Dtd dtd)
En plus du parsing des éléments intrinsèques de la DTD, nous avons donner la possibilité de documenter l'objet Dtd en implémentant une gestion particulière des commentaires.
Les principaux élements de parsing sont les mots suivants et en majuscule : <!ELEMENT, <!ATTLIST, <!ENTITY, <!NOTATION, PCDATA ou #PCDATA, CDATA ou #CDATA, EMPTY, ANY, #REQUIRED, #IMPLIED, #FIXED, NOTATION, NMTOKEN, NMTOKENS, ENTITY, ENTITIES, NDATA.
Dans cette version, il faut au préalable :
  • Définir un élément avant de définir ses attributs.
  • Définir une entité avant de faire référence dans une autre entité, dans un élement ou dans les attributs d'un élément.
Lorsque dans un fichier un ou plusieurs éléments ne sont pas définis une exception sera levée. Dans le message de l'exception, on aura la liste de ces éléments non définis.
En plus de ces élements les fichiers (DTD) à parser peuvent avoir un prologue caractérisé par :
  • le prologue est toujours à la première ligne lorsqu'il existe,
  • le prologue commence par <?xml et se termine par ?> .
  • Son parsing se fait à partir des mots clés suivants en minuscule : version= et encoding=
L'importation des DTD dans un DTD par souci de modularité est pris en compte dans le parsing de DTD.
Une gestion particulière des commentaires est prise en compte pour la génération des commentaires au niveau document et au niveau item du document.
  • Gestion des commentaires de niveau document : Normalement, pour qu'un commentaire soit ajouté à l'objet Dtd, if faudrait que le texte effectif commence par <-- suivi de @doc. Il peut avoir un ou plusieurs espaces entre les deux chaines de caractères.
  • Gestion des commentaires de niveau item : Par item nous entendons les élements, les attributs, les entités et les notations. Le parsing se fait sur la base des éléménts suivants : @name et @value.
Dans cette version :
  • les conditionnelles à savoir INCLUDE et IGNORE ne sont pas encore prises en compte,
  • Les espaces entre les valeurs d'une liste de valeurs ne sont pas acceptés par défaute,
  • Les doubles quotes sont automatiquement reconnues comme marqueur de valeur.
Comme extensions les plus urgentes, nous entendons :
  • Affiner la gestion des messages d'erreur de façon être le plus précis possible et ainsi faciliter le débogage des DTD,
  • Prendre en charge la gestion des conditions (INCLUDE et IGNORE),
  • Commenter d'avantage le code source,
  • Générer en html ou pdf une documentation de la DTD,
  • Etendre la gestion des commentaires de façon à typer les données et intégrer ce typage dans la documentation.
SUDAL
SereniX Unified Data Access Layer (SUDAL) est un framework d’accès aux données. Il permet d’accéder, de manipuler et de rendre persistant les données tabulaires de la même façon quelque soit la source (table de base de données, fichiers texte avec séparateur, fichiers texte avec des colonnes ayant des tailles fixes, fichiers excel, fichiers xml, liste d’objets, hibernate, JPA/EJB3, ResultSet…). Tous ces types de données sont manipulables sous forme de DataSet. Les datasets peuvent être créés individuellement, comme ils peuvent être obtenus à partir d’un DataSetManager.
En plus de manipuler les données sous forme de DataSet, SUDAL donne la possibilité de les manipuler sous forme de liste d’objet lorsque vous définissez un mapping entre les classes et les datasets du DataSetManager.
Les principaux composants de SUDAL sont :
  • DataSet : Un dataset est un container de données tabulaires (table de base de données, requêtes, fichiers texte, Excel et XML).
  • DataSetManager : est un gestionnaire de dataset. Les datasets sont regroupés en schéma et les schémas en catalogue par similitude avec les base de données.
  • ODM : Object Dataset Mapping est un gestionnaire de mapping entre les datasets et les objets métiers (de données).
Un dataset est une matrice des données à deux entrées : les lignes et les colonnes. Chaque dataset quelque soit son type est constitué de métadonnées et des données proprement dites. Les métadonnées sont bien entendu, des données qui décrivent le dataset et qui permettent de construire et de charger les données réelles.
Quelque soit le type de dataset, il est possible d’enregistrer son contenu dans :
  • Une table de Base de données grace aux classes ResultsetCacheData, RSDataSet et TableDataSet
  • Un Fichier Texte grace aux classes FileData et FWDataSet
  • Un Fichier Excel grace aux classes XlsCacheData et XlsDataset
  • Un Fichier Xml grace aux classes XmlCacheData et XmlDataSet
XDataSet a été conçu pour gérér les tables dynamiques et les listes d’objets dynamiques. Nous parlons de table dynamique ou de liste d’objet dynamique lorsqu’un même objet n’a pas la même représentation pour une même application. La représentation varie par exemple en fonction du l’acquéreur de l’application. Un XDataSet peut être constitué soit :
  • D’une partie statique et d’une partie variable,
  • D’une partie variable uniquement.
Exemple :
Dans certaines entreprises, ou dans certains pays, le sexe ou la réligion d’un client peuvent être obligatoires alors que pour d’autres il est hors de question que ces éléments figurent sur la fiche du client. On peut donc avoir comme partie statique, l’identifiant, le nom, la date de naissance et comme partie variable tout ce qui dépendra, des entreprises clientes, des pays, …
Au lieu d’avoir plusieurs tables de paramétrage, il est possible d’utiliser un seul XDataSet ce qui va limiter le nombre de tables à maintenir dans la base de données.
JoinedTable
Une JoinedTable est un dataset qui est composé d’une liste de dataset. Entre deux datasets consécutifs de la liste, la clé primaire du premier dataset est liée à la clé primaire du deuxième dataset. Donc la clé primaire du deuxième dataset est en même temps clé étrangère dans ce deuxième dataset. Pour un JoinedTable de deux datasets, chaque enregistrement du deuxième dataset est un complément d’un enregistrement du premier dataset. La notion de JoinedDataSet permet de simuler l’extension des classes.
UnionTable
Une UnionTable est un dataset composé d’une liste de datasets. Les données du dataset sont l’ensemble des données de tous les datasets.
Les datasets peut être gérés de façon individuelle ou de façon structurée. Un datasetManager permet une gestion structurée des datasets. Ils peuvent être liés et sont regroupés suivant la logique des bases de données en catalogue et schéma. Un catalogue est une liste de schémas et un schéma une liste de datasets.
Les différents types gérés sont les suivants :
  • La classe DataBaseManager qui permet de manipuler les objets d’une base de données via une connection JDBC.
  • La classe FolderDatasetManager permet de construire tous les datasets relatifs aux fichiers des répertoires de même que les clés primaires et tous les liens entres les datasets.
  • La classe XmlFolderDataSetManager est identique à FolderDataSetManager à ceci près que les fichiers des métadonnées sont des fichiers Xml.
  • Un XmlDataSetManager est utilisé dans le cas d’un seul fichier Xml qui contient toutes les données.
  • Un GridDataSetManager est une classe qui permet de regrouper plusieurs DataSetManager en un seul DataSetManager.
DataBaseManager
La classe DataBaseManager permet de manipuler les objets d’une base de données via une connection JDBC. Vous pouvez créer manuellement un catalogue, un schéma ou une table et par la suite les rendre persistant dans un système de gestion des bases de données. Vous pouvez aussi extraire tous objets d’une base de données (catalogues, schémas, tables, index, …) à partir des paramètres de connexion.
FolderDataSetManager
Les datasets manipulés dans ce cas sont des fichiers stockés dans un répertoire. Le répertoire lui-même est composés de deux sous répertoires l’un pour les métadonnées et l’autre pour les données réelles. La classe FolderDatasetManager permet de construire tous les datasets relatifs aux fichiers des répertoires de même que les clés primaires et tous les liens entres les datasets.
XmlFolderDataSetManager
XmlFolderDataSetManager est identique à FolderDataSetManager. La seule différence est que les fichiers des métadonnées sont des fichiers Xml.
XmlDataSetManager
Un XmlDataSetManager est utilisé dans le cas d’un seul fichier Xml qui contient toutes les données.
GridDataSetManager
Un GridDataSetManager est une classe qui permet de regrouper plusieurs DataSetManager en un seul DataSetManager.
Par ODM, nous entendons Object Dataset mapping ou en d’autres terme le mapping entre les datasets et les objets. C’est un mapping objet relationnel. ODM est un ensemble de classe de SUDAL qui permet de gérer le mapping des dataSets et des objets.
Dans le cas des types autres que les tables de base de données, des relations peuvent être définies entre les datasets. Les outils connus sur le marché (Hibernate, TopLink, …) permettent de définir le mapping uniquement entre les tables de base de données et les objets. SUDAL donne la possibilité de le faire avec tout type de dataset.
ODM permet de générer aussi les fichiers de mapping et de classes pour les frameworks Hibernate et Toplink et SUDAL. Pour la plupart des outils, après la génération on peut être amener à modifier manuellement les fichiers de mappings et/ou de classes pour avoir des noms convenables. Avant la génération, ODM offre la possibilité de :
  • Définir la logique de nommage des classes, champs et méthodes.
  • Choisir la langue (français, anglais, …) de génération des commentaires.
Exemple
EMPLOYEE
Nom Type Description
EMP_ID INTEGER INTEGER Identifiant de l’employé
EMP_CODE VARCHAR(10) Code de l’employé
EMP_FIRST_NAME VARCHAR(30) Prénom de l’employé
EMP_LAST_NAME VARCHAR(30) Nom de l’employé

Avec les outils du marché (Hibernate synchronizer, TopLink, FireStorm DAO, …) , la classe sera nommée Employee et nous aurons les champs suivants : empId, empCode, empFirstName, empLastName

Avec ODM, nous avons la possibilité de paramétrer le préfixe (EMP) de la table, de préciser le type de préfixe et de l’exclure du nom des champs. Nous aurons ainsi la classe Employee et les champs suivants : id, code, firstName, lastName
Pour Hibernate, les opérations suivantes sont possibles :
  • La génération des fichiers de mapping : A partir d’une connexion à la base de données, les fichiers de mapping sont générés en prenant en compte la personnalisation évoquée ci-dessus.
  • La génération du fichier de configuration,
  • La génération des classes : Les classes peuvent être générées à partir :
    • Des fichiers de mapping hibernate,
    • D’une connexion à la base de données,
  • La génération des fichiers de mapping orm.xml :
    • A partir d’une connexion à la base de données
    • A partir des fichiers de mapping hibernate
  • La génération des classes de données :
    • A partir d’une connexion à la base de données
    • A partir des fichiers de mapping orm.xml
    • A partir du fichier de mapping Hibernate
  • La génération des classes facades : Le nom des classes façades sont obtenu en ajoutant Facade au nom de chaque classe.
  • La génération du fichier persistence.xml;
Pour le mapping entre les datasets et les objets, nous avons préféré ne pas définir une autre spécification mais utiliser celle définie pour les EJB3. Ceci a l’avantage de facilité la portabilité.
La génération se fait à partir d’un dataSetManager.
Interface Utilisateur
L’interface utilisateur encore appelé interface homme-machine est un élément déterminant dans la facilité d’utilisation d’une application et même dans le choix d’une solution par rapport à une autre. Aussi avons-nous mis l’accent sur les composants de l’interface utilisateur dans le but de simplifier la vie des développeurs java en ce sens que l’essentiel de leurs efforts sera axé uniquement sur l’aspect métier. Tout l’aspect l’interface utilisateur d’une application peut être assuré par SereniX Unified Form Builder (SUForm). Ses principaux éléments sont :
  • Les tableaux,
  • SereniX EasyGridLayout,
  • Les fiches,
  • Les listes,
  • Les arbres,
  • Les extensions.
Les données du tableau peuvent être soit des datasets soit des listes d’objets métiers (liste des employés par exemple). Serenix donne la possibilité de créer des tableaux avec une ligne d’agrégat. Pour le faire, il faudrait préciser pour chaque colonne ayant un agrégat, sa fonction d’agrégat. Deux modes d’affichage des agrégats sont prévus :
  • Le mode externe : Quelque soit le nombre de lignes du tableau, la ligne d’agrégat du tableau est toujours visible. Cette ligne n’est pas partie intégrante du composant java JTable de base qui permet de gérer les tableaux. Ce mode est le mode par défaut.
  • Le mode interne : La ligne d’agrégat fait partie du composant java JTable. La ligne d’agrégat apparait en dernier dans le tableau. Si le tableau a beaucoup de données, cette ligne ne sera pas en permanence visible.
Un tableau quelque soit le type peut être composé de colonnes atomiques et des groupes de colonnes. Trois types de tableaux sont gérés :
  • Les tableaux simples,
  • Les tableaux croisés dynamiques encore appelés tableaux matriciels,
  • Les tableaux simples ou croisés avec regroupement des lignes.
Dans un tableau simple, le tableau est à l’image du dataset ou de la liste des objets. Autant le dataset ou la liste des objets a de lignes autant le tableau en aura.
Il est possible de créer des colonnes dont les valeurs sont calculées. Les valeurs des colonnes calculées peuvent être ou non stockées dans le dataset. Lorsque les valeurs d’une colonne calculée sont stockées dans un dataset, à la création du tableau, la valeur provient du dataset. Lorsque la valeur d’une colonne influençant le résultat de la formule de calcul est modifiée, les valeurs des colonnes dépendantes sont calculées.
Il est possible de définir des formules de calcul différentes pour chaque cellule d’une colonne calculée. Il en est de même des agrégats.Lorsque la valeur d’une cellule d’une colonne est modifiée, automatiquement les valeurs de toutes les cellules du tableau qui dépendent de cette colonne sont modifiées.
Les tableaux croisés
Un tableau croisé se réalise en deux étapes :
  1. Définition des données statiques (Voir le cas des tableaux simples),
  2. Définition de la partie dynamique : Il s’agit de définir la méta colonne dynamique qui permettra de créer les groupes dynamiques en fonction des données. A cette méta colonne il est possible de définir un méta groupe dynamique et ce dernier peut lui-même avoir un méta groupe dynamique parent.
Les tableaux avec regroupement dynamique des lignes
Pour avoir un tableau avec regroupement de lignes, il faut :
  1. Définir un tableau simple ou un tableau croisé dynamique,
  2. Définir une méta ligne dynamique qui va permettre de constitué dynamiquement les regroupements des lignes en fonction des données du dataset.
SereniX Easy Grid Layout Manager (SEGriL) permet de disposer avec la plus grande simplicité les composants visuels (label, champ de saisie, boutons, …) à la volée les uns après les autres sur un container sans se soucier de l’alignement et de préciser les positions. Les composants disposés sont parfaitement alignés et sont automatiquement redimensionnés lorsque la taille du container change.
Toutes les fiches qui sont construites avec SereniX Frame Builder utilisent comme layout manager SereniX EasyGrid Layout (SEGriL). Ce builder permet de gérer tout type de fiche des plus simples aux fiches composites très complexes.
Par extraction des champs : A partir d’une classe SereniX crée automatiquement un formulaire en procédant à la reflection pour retrouver les champs à placer dans le formulaire.
A partir d’une table de base de données, SereniX se base sur les colonnes de la base de données et crée automatiquement un formulaire. Dans ce cas, les champs sont disposés soit suivant l’ordre des champs de la classe soit suivant l’ordre des colonnes de la table.
Chaque fiche peut avoir ou non des boutons de commande. Il suffit de le spécifier.
Par spécification des champs : En plus de la classe ou du dataset (table de base de données, fichier Excel, …), le concepteur précise l’ordre d’apparition des champs et/ou pour les champs avec liste de valeurs, les listes de valeurs.
Ce type de fiche est une extension des fiches simples. C’est une combinaison d’une fiche simple et de plusieurs tableaux. La partie fiche est créée comme dans le cas des fiches simples. Pour la partie des tableaux de détail, la création se fait ainsi qu’il suit :
  • Cas des classes : SereniX extrait la liste des champs de la classe et la liste des classes détail. Cette dernière liste est obtenue à partir de tous les champs ayant un getter et un setter et dont le getter retourne un objet de type liste (java.util.List, java.util.ArrayList, java.util.Vector, …). Pour chacune des listes « détail », un tableau est construit.
  • Cas des datasets : Les datasets « détail » sont obtenus à partir des relations entre les datasets. Pour chacun des datasets « détail », un tableau est construit.
Les formulaires multipages sont des formulaires ayant plusieurs pages dont une seule est visible à la fois.
  1. Onglet : Dans le cas des onglets chaque page a une zone visible sur le formulaire permettant à chacune d’elle,
  2. CardLayout ,
  3. Assistant : Un formulaire de type assistant est un formulaire ayant plusieurs page équivalent chacune à une étape. La navigation à travers les pages est assurée par des boutons (suivant, précédent, terminer). Etant à une étape i, il n’est pas possible d’aller à une étape supérieure à i+1 si ces étapes n’ont pas encore été accédées au moins une fois.
Formulaire de type SplittedPane
Les formulaires de type splittedPane sont des formulaires divisés en deux zone.
Composite
Ce type de panel ou de formulaire est un panel composé de plusieurs éléments précédents (fiche Simple, maître-détail, tableau, liste, …). Chacun des éléments peut avoir sa source de données propre.
Exemple : Un tableau de bord qui ressort les ventes, les encaissements, les achats d’un mois donnée en un seul formulaire.
Nous ne nous sommes pas limité à donner la possibilité de créer facilement les tableaux, les listes et les arbres mais avons réalisé les extensions suivantes pour ces derniers.
Un bloc de commande est un composant qui contient un ensemble de boutons standards qui permettent de mettre à jour les données, les consulter, les importer, les exporter et les imprimer. Un bloc de commande peut être rattaché à un tableau, une liste ou un arbre. Pour qu’un bloc de commande soit rattaché à un tableau, une liste ou un arbre, il suffit simplement lors de la définition du tableau, de la liste ou de l’arbre, de préciser les boutons qu’on souhaite voir dans le bloc de commande. En plus des boutons standards, il est possible au développeur d’ajouter ses propres boutons.
  1. La localisation : La localisation consiste à :
    • Se positionner sur une colonne du tableau
    • Entrer des lettres pour rechercher les lignes du tableau commençant par cette série de lettres ou contenant cette série en fonctionnant du paramétrage du tableau.
    Pour que cette fonctionnalité soit fonctionnelle sur une colonne, il faudrait que la colonne soit de type texte et que la propriété « locator » soit positionnée à true.
  2. Tri : Lors de la définition du tableau, il est possible d’activer le tri des données d’une colonne lors qu’on effectuera un simple clic sur cette colonne. Il suffit que la propriété sortable de la colonne soit positionnée à true qui est la valeur par défaut.
  3. Filtrage des données : Un bloc de filtrage des données est automatiquement construit au dessus du tableau si au moins une colonne est définie avec la propriété filter à true. Dans ce bloc, il est possible d’entrer des conditions de filtre sur plusieurs colonnes. Ces différentes conditions sont reliées par un et logique.
En plus de rattacher les éléments suivants aux tableaux, listes et arbres, il est possible de rattacher sur un même formulaire, le bloc de visualisation et de mise à jour des données. Dans ce cas il faudra utiliser pour les tables, les arbres et les listes respectivement les classes DataTableViewer, ObjectTree et ObjectList. A moins que les formulaires à rattacher soient très complexes, il n’est pas nécessaire d’implémenter ces formulaires. Par défaut, des formulaires de type maître-détail seront créés.
Autres composants
En plus des composants XML et des composants d'accès aux données, SereniX offre aussi des composants très variés, entre autres:
SereniX a développé sous java un ensemble de classe de manipulation des expressions sous forme d’objet. SereniX a aussi développé un parser d’expression au format texte. La classe correspondante est ExpressionParser. Cette classe permet de parser des expressions arithmétiques, des conditions et des expressions conditions. Si le texte de l’expression est bien formé, le résultat de l’invocation de la méthode parse est un objet de type IExpression.
  • Une expression peut être uniquement une variable, une méthode mais pas un opérateur quelque soit sa nature.
  • L’expression peut être évaluée en invoquant sur le résultat la méthode getValue.
  • L’expression à parser peut aussi se trouver dans un fichier texte.
  • La synthaxe du language du parser d’expression est très proche de celle du langage JAVA.
La description ci-dessous présente les principaux éléments suivants :
  1. Les opérateurs arithmétiques
  2. Les opérateurs de comparaison
  3. Les opérateurs logiques
  4. Les expressions conditionnelles
Les opérateurs arithmétiques gérés sont :
Opération Symbole
Addition et signe positif +
Soustraction et signe négatif -
Multiplication ×
Division /
Modulo %
Les opérateurs de comparaison gérés sont :
Opération Symbole
Egal =
Inférieur ou égal
Inférieur <
Supérieur ou égal
Supérieur >
Différent
Compris entre BETWEEN
Compris dans la liste IN
Les opérateurs logiques gérés sont :
Opération Symbole
Et AND
Ou OR
Non NOT
Une expression conditionnelle contrairement à une condition peut avoir un résultat non booléen. Avec une expression conditionnelle, le résultat varie en fonction de certaines conditions. SereniX Expression Parser permet aussi de parser les expressions conditionnelles.
Pour qu’une expression conditionnelle soit reconnue comme telle, les consitions suivantes doivent toutes être vérifiées :
  1. L’ expression doit commencer par une parenthèse ouvrante ‘(‘
  2. Elle doit se terminer par une parenthèse fermante ‘)’
  3. L’ expression d’une condition se termine par ‘?’
  4. Le passage à un nouveau bloc composé d’une condition et d’une expression est matérialisé par le caractère ‘ ;’
  5. L’ expression de la valeur correspondant au sinon est directement placée après le caractère ‘ ;’ et clôturée par la parenthèse fermante. Le texte de cette expression ne doit pas contenir de caractère ‘ ?’.
Exemple
Si le client est une personnePhysique
   Renvoyer l’age du client
Sinon si le client est une personne morale
   Renvoyer l’age de création de l’entreprise
Sinon
   Renvoyer -1

Cet algorithme se traduit par le texte suivant :
(customer.getType() == ’P’ ? com.serenix.tools.math.Calcul.getAge(customer.getBirthDate()) : customer.getType()== ’M’ ? com.serenix.tools.math.Calcul.getAge(customer.getCreationDate()) : -1)

Explications :
Customer représente une variable (référence vers le client) permettant d’obtenir le client,

customer.getType(), customer.getBirthDate(), customer.getCreationDate() représentent des invocations de méthodes sur l’objet client,

com.serenix.tools.math.Calcul.getAge() représente l’invocation de méthode statique sur la classe com.serenix.tools.math.Calcul.

Condition :
La classe ConditionParser est une spécialisation de ExpressionParser. Ce parser n’accepte que le texte des comparaisons et des expressions logiques.
La gestion des fichiers jars se fait via les principales classes suivantes :
  • Jar : La classe Jar permet d’explorer le contenu d’un fichier .jar
  • JarManager : La classe JarManager permet d’explorer le contenu d’un ou plusieurs fichier .jar . Elle peut aussi être employée comme un chargeur de classe java (ClassLoader).
  • Composants graphiques : Les classes SelectorPane et JarExplorerFrame sont des composants graphiques permettant de sélectionner une classe se trouvant d’un JarManager.
La classe SClassLoader est la classe développée par Serenix pour le chargement des classes se trouvant dans un répertoire bien précis. Ce répertoire peut contenir des fichiers .jar et des fichiers .class.
Pour les fichiers .jar, SClassLoader utilise la classe JarManager pour le chargement des classes se trouvant dans ces fichiers .jar.
Ce ClassLoader peut être rattaché à sereniX Expression Parser pour permettre de reconnaitre aussi les classes se trouvant dans un répertoire bien spécifié. Ceci permet au parser une reconnaissance dynamique des classes.
La classe SereniX Calculator est l’outil destiné aux développeurs qui permet de définir des logiques des différents calculs possibles quelque soit le métier (primes d’assurance, indeminté à payer, commissions, agios bancaires, rubriques paye, …). Il est composé :
  • D’une interface graphique de paramétrage (en cours de développement),
  • Des composants intégrables à vos applications.