Re^6: Ideas for PerlMonks 2.0

I'd much rather see a drop-down that lets the user select the format they were writing, and "Classic PM" would be one of the options, along with Markdown, and maybe WSYIWYG. The default would come from user settings. The database table would consist of "ContentType" and "Content", and ContentType would select the rendering module which converts it to HTML, then you cache that in a separate layer. This is how many content systems work, including Drupal.

This way you have the option to go back and re-render everything to handle new ideas for site design that depend on changes to the tags, and you leave everyone with the ability to continue to edit their posts from before the cutover.

The entirety of the rendering for old PM format should be bundled up into a module and given unit tests. It's more effort, but I strongly feel this is the "right way" to handle it.

It also lets you iterate on Markdown rendering, later. You could internally have formats like "text/markdown-2024" and "text/markdown-2027" and show them to the user as simply "Markdown" while using the specific type stored in the table to keep rendering the content with the same renderer as it was written, so that new Markdown implementations don't break historic rendering.

Comment on Re^6: Ideas for PerlMonks 2.0

Replies are listed 'Best First'.
Re^7: Ideas for PerlMonks 2.0 by afoken (Chancellor) on Dec 11, 2024 at 08:48 UTC
I'd much rather see a drop-down that lets the user select the format they were writing, and "Classic PM" would be one of the options, along with Markdown, and maybe WSYIWYG. The default would come from user settings. The database table would consist of "ContentType" and "Content", and ContentType would select the rendering module which converts it to HTML, (or anything else, like XML) I strongly feel this is the "right way" to handle it. I had that in mind, too, but lacked the time to write it down. Having a "Classic PM" renderer would allow copying all content nodes from the existing PerlMonks to PM 2.0 in source form, no conversion needed, no complex interaction between PM 1.0 servers and PM 2.0 servers needed. Once all data is migrated to PM 2.0, PM 1.0 can be shut down. Looking at very old nodes, it might perhaps be useful to have an "Ancient PM" renderer in addition to the "Classic PM" renderer, because obviously the PM approved HTML subset has changed over time. But having just the "Classic PM" renderer would already be a great migration helper. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply]
Re^7: Ideas for PerlMonks 2.0 by jdporter (Paladin) on Dec 11, 2024 at 14:31 UTC
... a drop-down that lets the user select the format they were writing, and "Classic PM" would be one of the options, along with Markdown... The database table would consist of "ContentType" and "Content", and ContentType would select the rendering module which converts it to HTML, then you cache that in a separate layer. In fact, I started work on implementing exactly this here, a while ago. See document2 devdoclet. (If you can't access that, see Markdown is now supported for comments, experimentally)	[reply]