Rework Message Parser / BBCode System

[NetzwergX]

I just had a deeper look into the message and BBcode system, and i noticed that it is still as ugly as hell from an plugin developers point of view.

If you want to parse a message on your own, this is still nearly impossible. The only entry point is in the URLParser, but that is only executed, when the atomatic URL detection is active.

I would like to propose some changes:

1.) Divide the MessageParser from the BBCode parsing.
2.) Additional Parsers can be registered via PIP. You can specify in that PIP for what type of Message that Parser can be used.
3.) The message parser then loads all available Parsers and executes them.
4.) MessageForm also reads all available parsers and displays the appropriate option (e.g. "Use BBCodes", "Detect URLs automatically")
5.) of course a distinction is needed wether the specific parser should only be run once before saving the post (e.g. the URLParser, since it replaces text), or the parser is run in order to display the message. Maybe the former should be called "MessageFilter" and the latter "MessageParser".

This would not only allow developers to register own parsers to existing messages, but it would also allow them to easily create new types of messages, e.g. for a cms, where you might not wan't to use BBCodes at all, but e.g. markdown or other things. it would even allow for plugins to create parsers that depend on native libraries, e.g. textile u.v.m.

If something like this is worth consideration, i will start working on that and provide a demonstration / pull requests to message and BBCode system.

[dtdesign]

Wouldn't it be enough to add a few events in BBCodeParser instead?

[NetzwergX]

It might ease to add additional parsing, yes. But since the BBcode parser is that strong connected to the MessageParser, it won't help disabling BBcodes.

Since you can define diffenrent message types and make them searchable, it might indeed be a good idea to remove the necessity of a BBcode parser at all. Let's say you want to develop a wiki. You might want to use messages for that, and make them searchable by the search system. But you might not actually wan't to use BBCodes but a different markup instead. Or you might want to make a cms that has articles that can be searched. You could easily implement that as messages, but again, you might not want BBCodes for that, but e.g. markdown or textile or even another kind of markup.

I think being able to provide a bright variety of parser for different messages - one of them of course being the BBCode parser - would be a great benefit.

I think defining a set of "Filters" or "Preprocessors" - the current "URLParser" being one of that and a set of Parsers could be a very helpful implementation.

That way, every application or package can define their own filters and parsers for the different message types. The messageform itself could provide the neccesary option fields for the user to choose, when different parsers / filters were available.

Don't get me wrong - implementing some events in the BBCodeParser would of course be appreciated, if such a major rework of the BBcode system is unwanted at this time.

[dtdesign]

There already was a overhaul of BBCode system by improving the existing ones (e.g. the video bbcodes). Even though we can understand your needs, it still is a lot of work with just minor improvements. Please do not misunderstand me, such an improvement is always appreciated, but we want to focus on getting all this stuff stable for now.

Feel free to submit a pull request for additional events, I will be happy to merge it! Maybe we will focus on such BBCodes with the next version (WCF 2.1), but not for now. Sorry.

[NetzwergX]

Ok, i have already suspected such a thing and therefore asked first and not started implementing it. I will keep that in mind and will definitely come back to you with this when WCF 2.1 is arising.

I will have a careful look what events were needed in the system and then provide a pull request for that. Anyway, thanks for giving it some thought ;)