Discussion :

[aristeas]

lu

J'ai eu une réflexion récemment sur comment "externaliser", au mieux, les conditions d'un code java (du code) ?

Pour faire simple, prenons l'exemple d'une matrice en 2D qui contient des données en lignes et colonnes.
Le code du programme lit les données de la matrice.
Et pendant cette lecture j'aimerais que des conditions "externe au code" soient appliquées (dans un fichier texte modifiable, hors jar).
Du genre :
* la colonne 4 ne doit pas être vide.
* si une ligne, à comme valeur RR dans la colonne 15 alors la colonne 4 doit avoir DD
* ...


La meilleur solution est-elle de réaliser un "parser" perso (donc fichier texte structuré en conséquence) qui renverrait à l’exécution d'un bout de code, avec ses variables ?
Ou bien y a t il un meilleur moyen de réaliser ce genre de chose ?

Merci
@+

[joel.drigo]

Salut,

Oui, la solution "parser" est probablement la solution.

Mais il y a plusieurs façon d'aborder ça :

1. les actions ou "conditions" comme tu dis sont simples et peuvent être formalisées donc simplement (par exemple une expression du type "mot = valeur").
2. les actions sont complexes, quasiment du niveau du code Java lui même, avec des structures (options, boucles, etc)

Dans le premier cas, voir si un format standard n'est pas suffisant (du json par exemple, ou du xml, voir même un fichier properties). A la rigueur, des expressions régulières, et au pire un parser perso (un automate à états par exemple), mais...

Dans le second cas, il y a l'option JavaScript en utilisant l'interpréteur intégré (Nashorn). Cela te permet facilement d'exécuter du code provenant de fichiers externes, pouvant interférer avec les objets de ton programme Java (par un bridge, comme ce qu'on fait avec l'objet document d'un navigateur web). Tu pourras faire du chargement dynamique et même de la détection automatique de changement de fichier (avec un watcherservice).

On peut même envisager un mélange des deux (un JSon avec du javascript dans des propriétés texte du JSon).

[Pill_S]

Ça ressemble quand même pas mal au use case d'un moteur de règles. Par exemple, drools: www.drools.org. C'est moins puissant que du pur script mais ça permet d'éviter les risques d'un code malicieux (tu n'exposes que les fonctionnalités prévues)