Zest Writer un éditeur hors-ligne pour vos contenus ZdS

sortie de la 2.0.0 (03 aout 2020)

a marqué ce sujet comme résolu.

Je suis d’accord avec Aabu, et si je ne me trompe pas, il y a un certain moment c’était l inverse, moi qui proposait Java et toi qui était contre.

Je ne suis pas totalement contre en soit, mais je pense que ça demande réflexion avant de ce lancer tête baissée dans un travail relativement long et plus compliqué à maintenir.

J’avais déjà commencer, de mémoire j’avais fais une PR. J’avais regardé rapidement avec Victor pour ajouter une version de Zmd compilé directement dans la page web. Le problème est que Webkit (le moteur utilisé) ne prend pas en charge les nouvelle norme de javascript.

WinXaito

Je sais pas à quoi tu penses précisément quand tu dis "les nouvelle norme", mais du moment que t’as un bundle qui tourne dans un navigateur, le rendre compatible IE6 est trivial. (Je dis IE 6 pour que ce soit clair pour toi, mais en réalité c’est ECMAScript 5, la spec JavaScript de 2009. Rien de récent.)

+2 -0

Je reviens du coup donner quelques nouvelles.

Après avoir contacté victor (qui a activement participé au dev de zmarkdown), nous sommes rapidement arrivés à un POC qui fonctionne plutôt bien. Visiblement l’intégration de zmarkdown (JS) dans Zest Writer est possible et c’est possible aussi d’automatiser le build de zmarkdown qui servira à Zest Writer.

Donc l’idée est qu’à chaque release de zmarkdown, un tarball/build pour ZW soit généré et que Zest Writer s’en serve sans se soucier des détails sous-jacents.

La bonne nouvelle c’est qu’une nouvelle version de Zest Writer va bientot voir le jour. Et ça, c’est cool, parce que ça fait presque un an que le projet n’avait pas trop bougé.

Les premiers essais montrent qu’avec zmarkdown, niveau perf, c’est beaucoup plus fluide qu’avec python-zmarkdown (probablement du au fait que jython est un peu plus lourd). Donc on gagnera certaitement coté perfs, et coté taille du binaire final (qui du coup passe de ~120Mo à ~80Mo).

Donc ici c’est du js « client » ? Pas besoin d’installer un serveur node.js ?

qwerty

Pas besoin d’installer de serveur node.js, puisque c’est nashorn qui fait office de moteur Javascript. Le plus gros du boulot était de s’arranger pour que zmarkdown respecte les standard de nashorn (donc ECMAScript 5.1). Une fois que ça s’est fait, les portes sont ouvertes.

Donc ici c’est du js « client » ? Pas besoin d’installer un serveur node.js ?

qwerty

Non, c’est pas "client". Ce qu’on fait ici c’est substituer node par nashorn. Au lieu de faire node foo.js, firm1 fait jjs foo.js.

La différence entre node et jjs, c’est que node est un framework et un runtime récent. Nashorn n’est pas un framework et ne supporte que du vieux JS. Il fallait donc faire en sorte de compiler zmarkdown du JS moderne utilisant le framework node vers du vieux JS n’utilisant pas le framework node.

+0 -0

Arf firm1 y’a plein de trucs moches dans ce bout de code :

1/ Tu log rien, tu te contentes d’un printStackTrace, c’est vraiment une mauvaise pratique :(

2/ Tu te compliques énormément la vie pour lire un bête fichier, si tu veux un Path, fais juste une Paths.get(...), et de manière générale, pense à java.nio

3/ En parlant de ça, prends l’habitude de wrapper toutes les opérations sur les fichiers (lectures, écritures) dans des bloc "try-with-resources"

Bref, utilise java 7, on en est à Java 10 là :)

=>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
public class ZMD {

    ScriptEngineManager engineManager;
    ScriptEngine engine;
    Invocable invocable;

    public ZMD() {
        engineManager = new ScriptEngineManager();
        engine = engineManager.getEngineByName("nashorn");
        invocable = (Invocable) engine;
        try(Reader convert = read("js/convert.js"); Reader zmd = read("js/zmarkdown.js")) {
            engine.eval(convert);
            engine.eval(zmd);
        } catch (IOException | ScriptException e) {
            LOG.error("Could not evaluate JS scripts", e);
        }
    }

    public String toHtml(String md) {
        Object html = null;
        try {
            html = invocable.invokeFunction("toHtml", md);
            return html.toString();
        } catch (ScriptException | NoSuchMethodException e) {
            LOG.error("Could not convert md to html", e);
        }
        return null;
    }

    private static Reader read(String path) throws IOException {
        return Files.newBufferedReader(Paths.get(path));
    } 
}

C’est pas fou, mais c’est plus "récent" comme Java déjà.

+4 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte