This project is read-only.

Global Comment List Design Question

Topics: Business Logic Layer
Apr 4, 2009 at 10:19 AM
Edited Apr 4, 2009 at 10:21 AM
After solving the multiple blog issue with an SQL Server-specific blog provider, the next thing I want to take on is having a comment list in the admin pages. Seriously, the comment list is my landing page for blog management and moving to BlogEngine.Net without one will simply be too painful. Since this is one of the top requests that hasn't been addressed in the Issue Tracker, I feel that I am probably in good company with this. My goal here is to make it dead-dog easy for people (mainly myself) to migrate from Subtext to BlogEngine.Net and a comment list is a major pain point in that quest.

Digging into the source code I can see why this hasn't happened yet. Comments don't really exist as independent entities in BlogEngine.Net. They're always associated with their Post object. Indeed, updating (for approvals or what have you) is done through the Post object and I'd be willing to bet that the CommentView control will choke if the Post property isn't set.

But all that just makes the problem interesting. I'm not griping here. A Linq statement or two with an OrderBy attached to a gridview and you're golden.

What I want some input on is how best to tackle getting the Post object in my (as yet hypothetical) comment list in the admin pages. To do so, we'll need to keep track of not just the comment but also the Post it belongs to. I see two ways to do this and I don't have the information I need to make a proper determination on which way would be best to use.

Method 1: Add a Post property to the Comment object that references the comment's Post. This is the tidiest way to approach the problem and the direction I'd go if I were a member of the dev team. The drawback is that not being part of the design team means that I'd have to merge anything I did every time a new release was out or I wanted to synch up with the devs. Forkalicous. Ugh.

Method 2: Create a class that references both the Comment and the Post it belongs to. This is a little bulky because it means that your Bind and Eval are going to have to go an extra level to get the relevant information. Not as elegant, but it also means I don't have to worry about being messed up in future releases (or at least being messed up in future releases is a good deal less likely).

You could technically do a hybrid of the two methods by creating an object that inherits from the Comment object, but doing so means you still have a dependency you'll have to watch for merge purposes, it's just less likely to get stepped on. Also, unless you control the blog provider (and thus instantiating the comments as the new class when they're loaded from the database), you'll still have to cast to the higher-level object when putting your list together. Since I aim to make whatever I do usable by others without forcing them to use my blog provider, this isn't really that attractive.

In the normal course of things, I'd go with option 1, create and submit a patch, and hope it gets reviewed and accepted (probably after some go-round with the project devs and tweakage). Unfortunately, I've noticed that user submitted patches don't really have much uptake here. Indeed, I don't see any that have actually been marked as accepted or even rejected (though that doesn't necessarily mean that they haven't been).

So I'm inclined to go with option 2. I cringe, though, because I hope that since this is such a highly voted issue that it'll get picked up and added to the core. If that happens, I'd hate to have an unnecessary abstraction object hanging around for its own sake.

So anyway, I guess it really comes down to this question: what's the likelihood of user-submitted content making the core code? Or, more importantly, what's the likelihood of my submitted update making the core code? Any input is appreciated. I've noticed that many of the project people are active here so by all means, set me straight if my perceptions are off base.