3

I'm implementing a wiki style site and want to highlight changes made to articles between successive versions. Using htmldiff to highlight changes works great, except it is rather cpu intensive. I'm using the awesome vestal_versions plugin for versioning.

So how best to handle this? I considered having an on_create callback on version creation create a delayed job that processes and then stores the htmldiff processed article (in the version table row).

If this is a good approach, how can I extend vestal_versions without touching the gem? Or maybe there would be a better approach.

Any advice is much appreciated. :)

mark
  • 10,316
  • 6
  • 37
  • 58
  • @mark Can you post your ruby and view side code ? I want to implement the same thing with my rails application. So, I will get the idea. Thanks . – krunal shah Apr 22 '11 at 07:17
  • Hey Krunal. In the end I used a really good javascript diff http://blog.lotusnotes.be/domino/archive/2007-10-29-js-diff.html . – mark Apr 22 '11 at 08:26
  • I'll look out my old ruby implementation if you still want it though. – mark Apr 22 '11 at 08:34
  • @mark Thank you so much for the JS. I am storing data with html tags. Can we handle html tags also with this JS. Like in first version user added a simple text. And in the newer version if user has enter text with bullets. Can we handle html tags also with this JS ? Any Idea how to handle it ? Any Solution ? – krunal shah Apr 22 '11 at 09:37
  • 1
    I'm doing the exact same thing; compare the tags then escape the html. Here's my code: http://pastie.org/1821966 – mark Apr 22 '11 at 10:09
  • @mark are you using jQuery or prototype ? – krunal shah Apr 25 '11 at 06:10

1 Answers1

1

If you are already having scaling issues, I would push it to the browser if you can. How much work would it be to port htmldiff to Javascript? If you can push the CPU load to the browser it would be a win.

Snowhare
  • 952
  • 5
  • 7
  • Hi Benjamin and thanks for your reply. It might have been cool to do this client side but I'd rather not hang the users browser on larger documents. It's not a scaling issue really, I'd just rather have it done in the background on a low priority so as not to make the editing user wait during server load. – mark Jun 13 '10 at 18:21
  • In the end I did exactly that. – mark Apr 22 '11 at 08:25