Re^4: Site HTML filtering, Phase II (way fwd)

I came up with an idea that I might like for moving forward regarding this type of change. I'd add a field to the node table for 'format' and a corresponding user setting.

All existing nodes would be tagged 'e2'. New users would start at 'pc' (which would be like simplified POD: preserve blank lines and treat paragraphs containing indented lines like code). When you compose a node, it'd default to your selected input format but you could select another.

But trying to support too many input formats would probably be a mistake, so new formats should probably be added slowly and deliberately.

Just the start of an idea...

- tye

Comment on Re^4: Site HTML filtering, Phase II (way fwd)

Replies are listed 'Best First'.
Re: Re^4: Site HTML filtering, Phase II (way fwd) by Corion (Patriarch) on Feb 12, 2004 at 08:57 UTC
I also came close to proposing that idea, but held back on it, because that way, we lose the option to store a "clean" version in the database. While the "new way" would be much more flexible, it also requires re-rendering of the format into HTML on each load from the database. I don't know how much of the re-rendering is currently done, so maybe there is no additional hit, and maybe the caching is already aggressive enough to allow this.	[reply]
Re^6: Site HTML filtering, Phase II (stow cleaned) by tye (Sage) on Feb 12, 2004 at 09:07 UTC
Replacing the node 'as typed' in the DB with some cleaned up version would be a mistake in my book. It is very intollerant of coding mistakes or even allowing improvements, and it often isn't nice to the author. Caching a cleaned copy in addition to the original is fine (but we don't do it and I doubt it'd be a big win just yet) -- and this is possible with the scheme I proposed. - tye	[reply]


There's more than one way to do things
	PerlMonks