Système de plugin about zest-writer HOT 27 CLOSED

Bonne idée, mais ça serait colossal comme boulot étant donné que l'appli n'est pour l'instant pas pensé pour. Mais on peut dores et déjà développer dans ce sens pour la suite.

from zest-writer.

Oui bien sur, cest pas tout simple a mettre en place.

Je n'ai jamais fais sa, tu as quelques conseil a me donner pour un facilité ce futur travail?

from zest-writer.

Je n'ai jamais fais sa, tu as quelques conseil a me donner pour un facilité ce futur travail?

Le truc c'est que pour un système de plugin il faut mettre en place une API (une interface Java quoi) qui sera generique à tous les plugins. Un plugin sera juste un jar à télécharger et à charger dans le système de plugin.

En gros c'est l'API qu'il faudra bien penser, ce qui necessite de définir ce qu'on veut que nos plugins fassent.

from zest-writer.

https://github.com/WinXaito/zest-writer/blob/plugins/src/main/java/com/zestedesavoir/zestwriter/plugins/PluginsLoader.java#L35

Ici et à la ligne 30, le résultat n'est pas le bon... J'aimerais obtenir ce dossier: https://github.com/WinXaito/zest-writer/tree/plugins/src/main/resources/com/zestedesavoir/zestwriter/plugins

from zest-writer.

Pour information tu obtiens quoi entre ---Start List plugins--- et ---End List plugins--- ?

from zest-writer.

Le dossier plugins, mais le mauvais (Celui dans les build qui contient mes classes compilé (PluginsLoader.class, etc.))

from zest-writer.

Ah ça c'est normal, quand ton projet est compilé, tout passe dans ton répertoire de build. Et tu as donc tes classes ainsi que tes ressources dans ce même répertoire. Le contenu de ton répertoire plugins dans src sera le même que le contenu de ton répertoire plugins dans build.

Est-ce qu'il y'a une raison particulière pour laquelle tu veux explicitement le répertoire plugin de src/main/resources ?

from zest-writer.

Euh bah pour placer les plugins. En l'occurence mon "FirstPlugin.jar", et il ne se trouve pas dans se dossier la après la compilation.

from zest-writer.

Ah je comprend mieux. Mais je pense que tu pars sur la mauvaise solution. Tu ne devrais pas mettre les plugins dans ton répertoire projet. Car lorsqu'il sera empaqueté, il ira dans un jar et tu n'aura pas la possibilité de rajouter un nouveau plugin à l'intérieur de ton jar. De plus même si tu arrivais à trouver un moyen de rajouter les plugins dans ton jar, à chaque mise à jour les plugins dans ton jar seront écrasés.

Je te conseillerais la dessus d'avoir une variable a renseigner dans le conf.properties qui contient le chemin explicite vers le répertoire dans lequel les plugins de l'utilisateur seront installées.

from zest-writer.

Oui effectivement.

from zest-writer.

J'aimerais juste savoir, par rapport à ce que j'avais proposer, c'est à dire mettre le module de rendu (Donc Jython et compagnie) sous forme de plugin.

Ceci afin, pour les gens qui se plaignait que Zest-Writer prenait énormément de RAM, ainsi que ceux qui ont une petite connexion et qui ne veulent pas l'installer de leur facilité la vie.

On pourrait imaginer un autre plugin qui demande à un serveur (VPS) de faire le rendu, donc avec nécessité de connexion. (Mais bon, on ne peut pas avoir le beurre et l'argent du beurre).

(Et au passage, c'est déjà plus ou moins fonctionnel ! Création d'un JAR pour le plugin, sont importation, interprétation et pour le moment gestion des Event de la fenêtre principale)

from zest-writer.

Bonne question.

Mon avis la dessus, c'est que l'application se doit rester massivement utilisable hors ligne, sinon on en perd un gros intérêt.

L'idée d'avoir le module de rendu de Zds (avec jython et cie) en plugin est superbe. Par contre l'idée d'avoir un serveur qui fasse le rendu me séduit moins car on aura du mal à avoir un truc qui fasse du temps réel correctement, et je ne suis pas sur d'avoir un serveur à disposition dimensionné pour ça.

Maintenant, moi je vois plutôt la possibilité d'utiliser un autre moteur de rendu markdown dispo en hors ligne, plus léger et écrit en pure Java(oui je pense très fortement au formidable pegdown) quitte à ce qu'il ne soit pas compatible full syntaxe zds. ça permettrai d'avoir un éditeur markdown sur lequel on peut choisir son moteur de rendu. Ce qui rendrait l'éditeur utile pour d'autres que les auteurs de ZdS par exemple.

Voilà un peu ma vision des choses, dit moi ce que tu en penses à la lumière de ça.

Et au passage, c'est déjà plus ou moins fonctionnel ! Création d'un JAR pour le plugin, sont importation, interprétation et pour le moment gestion des Event de la fenêtre principale

Ah ça je savais pas. Mes yeux brillent. ___

from zest-writer.

Par contre l'idée d'avoir un serveur qui fasse le rendu me séduit moins car on aura du mal à avoir un truc qui fasse du temps réel

Nonono :p dans cette version "légère" je pensais juste mettre un bouton pour avoir le rendu quand l'utilisateur le désire. Pas du temps réel.

Maintenant, moi je vois plutôt la possibilité d'utiliser un autre moteur de rendu markdown dispo en hors ligne, plus léger et écrit en pure Java(oui je pense très fortement au formidable pegdown) quitte à ce qu'il ne soit pas compatible full syntaxe zds. ça permettrai d'avoir un éditeur markdown sur lequel on peut choisir son moteur de rendu. Ce qui rendrait l'éditeur utile pour d'autres que les auteurs de ZdS par exemple.

Cest a toi de voir. Pourquoi pas l'intégrer aussi sous forme de plugin.

On aurait donc 3 types de version selon les plugins:

• Une version lourde mais avec un rendu au top
• Une version moyennement lourde, mais avec un rendu pas 100% exacte
• Une version légère sans système de rendu instantané (mais éventuellement par requête sur un serveur)

from zest-writer.

Je rejoins ta conclusion. Ceci dit, je prioriserais les 2 premiers
objectifs, ne serait ce que parce que pour le troisième il faudra assurer
la dispo d'un serveur.

Le mar. 3 mai 2016 12:15, WinXaito [email protected] a écrit :

Par contre l'idée d'avoir un serveur qui fasse le rendu me séduit moins
car on aura du mal à avoir un truc qui fasse du temps réel

Nonono :p dans cette version "légère" je pensais juste mettre un bouton
pour avoir le rendu quand l'utilisateur le désire. Pas du temps réel.

Maintenant, moi je vois plutôt la possibilité d'utiliser un autre moteur
de rendu markdown dispo en hors ligne, plus léger et écrit en pure Java(oui
je pense très fortement au formidable pegdown) quitte à ce qu'il ne soit
pas compatible full syntaxe zds. ça permettrai d'avoir un éditeur markdown
sur lequel on peut choisir son moteur de rendu. Ce qui rendrait l'éditeur
utile pour d'autres que les auteurs de ZdS par exemple.

Cest a toi de voir. Pourquoi pas l'intégrer aussi sous forme de plugin.

On aurait donc 3 types de version selon les plugins:

• Une version lourde mais avec un rendu au top
• Une version moyennement lourde, mais avec un rendu pas 100% exacte
• Une version légère sans système de rendu instantané (mais
  éventuellement par requête sur un serveur)

—
You are receiving this because you commented.

Reply to this email directly or view it on GitHub
#63 (comment)

from zest-writer.

Pour les plugins, il faudrait avoir une certaine documentation. Je la fais où et comment ?

from zest-writer.

Je pensais a mettre en place le système de documentation, mais je ne me suis pas encore fixé sur la techno. Mais ça sera certainement à base de markdown.

Je dirais que dans un premier temps tu peux créer un dossier docs à la racine dans lequel tu rédige la doc des plugins.

from zest-writer.

Ça joue merci !

from zest-writer.

Petite question encore, comment je fais pour lancer ZW en mode debug ? (Pour avoir les logger.debug("") ?

from zest-writer.

La conf par défaut est déjà configurée en mode debug.

from zest-writer.

Ah pour les logs oui, mais y a pas moyen d'avoir directement dans la console ?

(Bon j'avais pas penser au fichier logs donc je peux au moins les voir maintenant)

from zest-writer.

il y'a moyen de l'avoir dans la console oui. faudrait que je fasse un log4j.properties spécial dev

from zest-writer.

J'aurais besoin de ton avis ici.

Actuellement, je gère quelques événement, et le plugin peut récupéré la classe MainApp, donc le plugin peut avoir accès à toute l'application.

Je ne pense pas que ça soit dérangeant, c'est même mieux, car le plugin est libre de faire ce qu'il veut et je ne dois pas recodé toutes les fonctions pour lui appliquer des "limites". De toute façon c'est à l'utilisateur de faire attention à ce qu'il installe, car rien n'empêche un plugin d'exécuter du code malicieux et ce pour tous les systèmes de plugins que je connaisse.

Je pense arriver gentiment au bout pour cette PR.

J'aimerais pouvoir géré les plugins avec un Downloader intégré, et éventuellement mettre une restriction pour n'autoriser que les plugins open-source et éventuellement validé. Mais je pense qu'il s'agit d'une PR à part.

from zest-writer.

@firm1

from zest-writer.

L'idéal serait de ne pas forcement avoir access a toute la MainApp, mais
bon en soit c'est pas très grave, il faudra a un moment faire une refacto
de MainApp (qui porte trop de chose) et on verra a ce moment là.

Je vais juste prendre le temps de tester ça proprement (et éventuellement
te pousser une PR si besoin).

Le sam. 14 mai 2016 12:12, WinXaito [email protected] a écrit :

@firm1 https://github.com/firm1

—
You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
#63 (comment)

from zest-writer.

Yep merci

from zest-writer.

Hello, du nouveau ici ?

from zest-writer.

J'avoue que j'ai eu la flemme de m'y pencher. Je regarderai ça sans doute
demain.

Le jeu. 16 juin 2016 19:50, WinXaito [email protected] a écrit :

Hello, du nouveau ici ?

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#63 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AFyPX0iRC0F0bg0Qc3maXnsBV9EYPtUCks5qMYzMgaJpZM4ILZ64
.

from zest-writer.