Customizing SMF > Forks Discussion
BBCode pre-parsing
青山 素子:
That assumes you care about fidelity. Most forums won't.
AngelinaBelle:
If you don't care, then it is simple. Store the pre-parsed code, and don't allow editing ever again.
Allowing editing with the "wrong" set of tags could cause problems, as the html would be un-parsed incorrectly, and some html could not be "unparsed" at all (for example -- if you previously permitted a marquee, but now do not).
Wikis don't preparse. But a wiki and a forum are used very differently.
Kindred:
I am not sure I like the idea of preparsing....
it would make upgrades which change the parsing harder... and take more db resources....
on the other hand, I think we could definitely use the db to store the basic parsing parameters for each tag (thus allowing an admin or a mod to add new BBC simply) and read that out into a file upon save....
(getting the best of both worlds, IMO)
AngelinaBelle:
--- Quote from: Kindred on August 17, 2011, 12:40:11 PM ---it would make upgrades which change the parsing harder
--- End quote ---
Unless you prune away the ability to reverse-parse "previous version" posts.
--- Quote ---... and take more db resources....
--- End quote ---
Probably not double, except for certain especially formatting-rich posts.
And maybe gallery-rich and embedded-video-rich posts.
You'd probably have to do a side-by-side comparison to see the difference.
That's what is so interesting about forks. You've got people bold enough to rip out SMF functionality and replace it with the "what-if" just to see what would happen.
--- Quote ---use the db to store the basic parsing parameters for each tag (thus allowing an admin or a mod to add new BBC simply) and read that out into a file upon save....
--- End quote ---
That might be handy.
Kindred:
yes, that "store in database, but read out to a file for usage" is something we're looking at for the next main SMF release... it makes for a possibility of a nice admin tool, while still allowing the system to run without significantly increasing database hits
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version