Je développe un composant de thème où je souhaiterais faire quelque chose de similaire à :
main() {
printf("Hello World!\n");
}
ce qui donne :
main() {
printf("Hello World!\n");
}
J’utilise api.decorateCooked() pour cela, mais comme le contenu est déjà cuit, tous les espaces « redondants » ont été supprimés, par exemple l’espace avant printf dans l’exemple ci-dessus.
Comment puis-je accéder au texte « non cuit » tel qu’il a été saisi par l’utilisateur ?
Pour être clair ; ce que je souhaite prendre en charge avec mon composant de thème, c’est permettre à l’utilisateur d’écrire quelque chose comme :
Est-il possible d’installer un plugin personnalisé sur une instance Discourse hébergée par Discourse avec un plan gratuit ? Je n’ai pas réussi à trouver comment faire, en tout cas.
Serait-il possible d’ajouter une prise en charge de raw pour les composants de thème ? Si oui, accepteriez-vous une PR pour cela ?
Le helper wrap ne fait pas ce que je demandais. Il supprime également la mise en retrait.
Malheureusement, nos offres gratuite, standard et entreprise ne permettent pas d’utiliser des plugins personnalisés. Nous utilisons un cluster qui héberge de nombreux clients différents ; nous n’avons aucun mécanisme pour exécuter un plugin uniquement pour un client.
Envisager la possibilité d’injecter une extension Markdown via un composant de thème est quelque chose à quoi j’ai réfléchi par le passé, mais nous n’avons aucun projet concret pour l’ajouter. Ce serait extrêmement difficile à mettre en œuvre.
Et si vous utilisiez un double encapsulage ? Cela permettra certainement de conserver tout le retrait.
[wrap=test]
```
1
1
3
```
[/wrap]
Peut-être qu’utiliser simplement quelque chose comme ceci fonctionnera ; vous aurez un élément distinct avec lequel travailler :
C’est extrêmement difficile aussi pour vous, ou seulement pour quelqu’un comme moi sans connaissance préalable de l’implémentation ? Où réside la difficulté ? Serait-il plus facile de faire quelque chose de plus simple qu’une extension Markdown complète, comme un accès en lecture seule aux données brutes ?
Le front-end ne reçoit pas le contenu brut des messages. Il ne reçoit que la version formatée. Cela signifie que les charges utiles envoyées au client sont plus légères. De plus, le serveur est ultimement responsable de la conversion Markdown > HTML. Si nous faisions tout cela à l’exécution dans le navigateur, nous ajouterions beaucoup de coûts supplémentaires et devrions nous soucier de vecteurs de sécurité complexes.
Pour être clair, vous savez bien que si ce que vous voulez vraiment, ce sont des blocs de café, vous pouvez entourer les blocs de code avec trois accents graves, non ? Je ne peux pas dire dans quelle mesure votre exemple est une métaphore.
@pfaffman Je ne sais pas ce que tu entends par « blocs de café », mais oui, je sais bien que trois accents graves génèrent un bloc de code.
Je ne comprends pas pourquoi mon exemple devrait être une métaphore. Pour quoi faire ? L’image que j’ai publiée est une capture d’écran destinée à montrer ce que mon composant de thème génère pour le code donné.
Oui, je suppose. Je n’ai pas encore vu le plugin Math, mais le concept semble similaire. Il remplit la même fonction de base que Discourse Graphviz, mais celui-ci permet des fonctionnalités beaucoup plus avancées, comme des transitions animées entre les graphiques, et offre une multitude d’options pour le contrôler et le styliser.
Voici le dépôt GitHub si cela vous intéresse. Il n’est pas encore officiellement déployé nulle part, car je dois d’abord rédiger une documentation détaillée sur son utilisation.
Alors, cela semble fonctionner, et peut-être que je passe à côté de quelque chose : la solution consisterait à soumettre vos modifications sous forme de PR, et elles seraient alors disponibles sur les offres professionnelles.
Désolé, je ne comprends pas ce que vous voulez dire. C’est un composant de thème qui peut être installé sur n’importe quelle instance Discourse via l’interface web par son administrateur, quel que soit le plan choisi.
Je ne comprends probablement pas bien. Mais il semblait que ce que vous voulez faire, c’est étendre le plugin graphviz pour prendre en charge davantage de fonctionnalités de Graphviz, et que cela aurait plus de sens d’intégrer ces fonctionnalités dans ce plugin.
Cependant, je ne suis pas vraiment sûr de ce que vous recherchez, donc je pourrais complètement me tromper.
Maintenant, je comprends ce que tu voulais dire. Non, comme nous sommes sur un plan gratuit, nous ne pouvions pas utiliser ce plugin, c’est pourquoi j’ai développé un composant de thème à la place. Les fonctionnalités supplémentaires étaient une sorte de bonus qui ont été facilement ajoutées car elles reposent sur une autre bibliothèque que le plugin existant.
Les plugins et les composants de thème sont très différents, donc je ne pense pas qu’il soit possible de réutiliser du code entre eux. Cependant, je suppose qu’il serait possible pour quelqu’un d’ajouter la même fonctionnalité au plugin existant s’il y est intéressé.
