views:

454

answers:

4

Any advice what has worked for you when dealing with user-entered markup, e.g. wiki or markdown. I have both CPU & database space costs, so I'm not sure which way to go.

  1. Store markup in database & render to html on the server for each pageview. (Less database space but more CPU usage)

  2. Store markup in database & render to html on the client using javascript. (Possibly more difficult to implement)

  3. Store just the rendered html in the database & convert back to markup if editing required. (Again, possibly tricky to implement).

  4. Store both html & markup in the database. (Double the database space).

  5. Something else.

(I'm using MFC & Linqtosql).

+7  A: 

I would store it in the database as Wiki markup, then hold the transformed HTML output in memory in a cache on the webserver. Whichever web technology you're using, all should support this - a basic tuple (hashtable) keyed on the url, or id, or similar.

Chris S
Beat me to it, +1 for you.
Aaron Maenpaa
+1  A: 

I would store the markup and render html server side on the fly. You can use server side caching to reduce the amount of actual computation you perform and you get to keep a representation that has reasonable semantics and can be rendered to text/html/pdf if needed.

Aaron Maenpaa
+1  A: 

Easiest way would be to store markup and render the HTML on demand in a cache (possible on disk or in memcached onjects) with the timestamp of render. That way you can check whether you need to render again because the markup has changed or just serve the cached HTML. That is the way most Ruby on Rails apps/CMS work.

Keltia
+1  A: 

I would store it in the database as RST markup, and transform to HTML as needed. Since you're probably using a front-end (e.g. JSP, PHP, Django or something else that renders a template language) the additional processing for RST won't introduce much overhead.

Actually measure the actual overhead of rendering the markup into HTML before deciding to implement a complex caching mechanism.

The "(Less database space but more CPU usage)" isn't a measured fact, it's an assumption that may turn out to be not true.

S.Lott