Tips On Rolling Your Own Comment System As a practical learning experience, I'd like to try implementing a comment system for my weblog since I would prefer to store all my data in one place as opposed to going the we::blog route.  I'm pretty impressed with the system you've set up here, so I'm obviously curious about how it works. Any tips you'd be willing to offer would be a great starting point, i.e. - what kind of server side scripts are you using for authenticating, posting, parsing and such, what are you using as a database, anything you learned that you would do differently, etc... Thanks. posted by BionicRoachFebruary 25, 2003 at 18:25 [ e ]

email me, I'll send you the code Well, rolling your own can be a pain since it will probably lack lots of fancy features. Some issues with mine. * the WYSIWYG editor only works on IE5.5+ and only under Windows.  I have to try to figure out if the user is running IE5.5+ under Windows and dish up the WYSIWYG one or the plain text one.  I'm not sure if it's always correct * Because I allow some HTML I have to parse that crap so it doesn't mess up my site.  For example if someone put a tag with no closing tag.  Actually, my comment input/editing system doesn't deal with that, the part that displays the comments does. * I have no system in place for looking up users etc.  The database is on my server but I have written no interface for it so for example I can't edit users easily, I can't send someone their forgotten password, etc. * I have no automatic forgotten password system (secret question, secret answer type of thing) * I have to try to prevent users from posting really long lines.  That gets more problematic if you allow font sizes (which is why I took that option out) * I actually have one database table for each page.  Instead of having one giant table for all messages with each message having a page ID.  I'm not sure which is better but I'm just using the CSV file driver for perl DBI:: * because it's CVS based I have to escape / unescape lots of stuff as I write it to/read it from the database. * other parts are kind of hacked (optimized).  For example the latest message list is it's own database.  In a fancier database you might just ask it for the list of the top 30 messages.  The problem is that's a slow operation if you don't have a real database system.  It's probably not all that fast even then.  My system uses it's own table so it takes almost no time to display since it can just be used directly.  But, to keep it reasonable it only stores the top 30 and if a message is deleted it will shrink to top 29 until a new message is added (otherwise I'd have to search all messages to find the 30th oldest one) posted by greggmanFebruary 25, 2003 at 21:53 [ e ]