Adding new message types

Antony74

Hi,

Is their a 'nice' way to add a new message type to Vanilla? i.e. something which is more 'modular' or 'object-orientated' than the hack I've performed here:

https://github.com/Antony74/affogato

Existing message types are Html, BBCode, Markdown, and Text. I've added a small extension to Markdown which allows Processing.js sketches (art and interactive animations) to be included within forum messages (mainly to facilitate discussion of the Processing programming language).

It's pretty well self-contained other than a few require() statements and a new button, and Vanilla is great to work with and extremely hack-friendly, but the disadvantage of this approach is it has to be merged with new releases (or other hacks) - which has already happened to me once with those security fixes released 4th May.

I've got the forum running here

http://affogato.org/

You're welcome to play, and since I'm a Vanilla newbie, there are likely to be other things I could be picked up on ;-)

Thanks,

Antony

vrijvlinder

Wow that is super cool !! Would like to know how you hacked it to be able to render in post.

Antony74

Thank you. Yes, I am rather pleased with the result myself, which is why I'm keen to find a way to package it up more neatly.

I'm not sure which bit of the process you're asking me about. There's a function in vanilla called markdown() which takes a string of markdown and returns a string of html. At the heart of it is some arrays of functions. Each function is called in turn and contains a regular expression. So I added my own function to one of these arrays, and wrote a regular expression to match my new piece of markdown syntax. The php function preg_replace_callback gives you a nice callback for each match in the markdown string, so I wrote my callback function to return the html I wanted: It's very easy to add a Processing.js sketch to a webpage, there's a good tutorial here

x00

I wouldn't fork vanilla entirely to do this, you are bit left out in the cold having to support the entire code base just for one feature. You have the option of plugin.

Fist consider if using processing.js is going to have its own Format Type, or something you could be within other Types such with a short code (like spoilers, smiles, Latex, etc).

It seem to me you will not get much clash with mardown or html. So could be a post processed.

I think using code block although interesting, would be not be my first choice. As code display is different then running it. On the other hand if you put the code display first, then the play an as option this would make sense form my perspective. Otherwise you can use some other way of marking the code. The other reason I would separate is why assume that every piece of code is processing code. People might post all sorts of code.

Antony74

Thanks x00

The syntax of the code block was borrowed from Git Flavored Markdown - the programming language can be named when the code block is opened.

```Processing
rect(20,30,40,50);
println("hello, world!");
```

So if you don't want the code to be run, you just omit the word "Processing". I take your point about this confusing the role of the code-block, but I think that's preferable to dreaming up an entirely new piece of markdown syntax.

And I'm afraid there are clashes with post-processing - bits of code will be incorrectly recognized as markdown (and pre-processing would clash too because Vanilla needs to be in control of what html tags a user can insert). :-(

But you're totally right about everything else - there's no way I want to be maintaining this as a fork if I can help it! I am very interested to learn that there are existing modules which post-process forum messages. Perhaps you could recommend one for me to take a closer look at?

Antony74

By the way, I think it's fantastic that you're challenging me on all the right points check I've thought this through!

R_J

It seems like you can use a custom BBCode formatter but no custom Markdown formatter, so "simply" installing your already working Markdown formatter as an alternative Markdown formatter will not work. You could add your new format, but that sounds like too much fuzzing around...

You could write a plugin which does something like that:

public function base_afterCommentFormat_handler ($sender) {
  $sender->EventArguments['Object']->FormatBody = YourMagic($sender->EventArguments['Object']->FormatBody);
}

x00

You could pre-process and put into <pre> and the preg_replace_callback function should be Gdn_Format::Text or htmlspecialchars

On the client side use .text() to pass to processing.

x00

The hook you use DicussionController_BeforeCommentBody_Handler manipulating $Sender->EventArguments['Object']->Body

If you want a completely Format neutral aproach, you could any pre tags that won't get striped then with use AfterCommentFormat

To change them to <pre> tags.

Antony74

Yes, that's great guys. I could definitely come up with something that works through some combination of pre and post-processing.

Can I draw your attention for one sec to the fact the Markdown formatter is intended to be extensible in an object-orientated fashion, it's just the code which includes it with a require_once statement that is inflexible.

So that makes it a race between markdown.php and affogato-markdown.php, whichever is included first wins control of the all important MARKDOWN_PARSE_CLASS define. So possibly my plug-in just needs affogato-markdown.php together with a well placed require_once statement to ensure it 'wins the race'.

x00

For consistency sake it makes sense that formatter are predicable and backward compatible. As there are different markdown flavours, it makes sense to label them differently.

There are other way to override the formatters due to he way vanilla auto-loads, I just don't think it is relevant to this case.

Like the quotes plugin you can make it work for different formatters.