In terms of my usage patterns at TT, I don't see the value in separating them. I block user X, and I'm good with that, except that someone reacts to post #1557, and I want to go and see what that post says. I do not want to unblock the poster, I just want to know what this particular kerfuffle is. I don't want to set up a scenario where I have re-blocking overhead to do after I click to read that post.
My "add-on" design would cover that. I'm imagining that we first setup code like,
if (user is blocked) then [don't display post] else
[display post]
Once that is working and in production, we could always later add a post-specific unblocking add-in like,
if (post is unblocked) then [display post] else
if (user is blocked) then [don't display post] else
[display post]
I thought there might be value in doing it in stages (getting something in production more quickly). If it's just as easy to do it all at once, then ignore me.
That's insane troll logic.
Seriously, I think you're being redundant. The logic is applied to each post. [post is unblocked] == [view specific post]
Wahey. What fun.
The whole of Scotland *blueyonder* just went down.
All good now, we're back up and cruising on impulse. :-P
t relief
OK, I see what you're thinking. I actually missed the first line, even tho I copied it. Color me embarrassed.
t kicking back to watch the coders duke it out. Really, it's better than the Discovery Channel and World Wrestling combined
Personally, I would check if the user was blocked before you check the specific post. I guess it's just a question of how much you think people are going to be using the blocking feature - if you think they'll be using it a lot, then check that first, because if the user is unblocked, it doesn't matter about the specific post, and, in fact, I think it will be impossible to have a post unblocked unless the user is blocked.
Personally, I would check if the user was blocked before you check the specific post.
Yeah, I was just trying to make the logic as simple as possible to explain what I meant. If there are performance gains by doing it the other way, then it's just as easy to code.
If there are performance gains by doing it the other way, then it's just as easy to code.
Probably would be, but I'm just guessing, not knowing anything about how the rest of it is coded, or, again, what the assumptions are as far as how frequently it will be used.
Also, just a thought, but you could put in a "Block my post" option when posting - this would be better than whitefont for spoilers. Then, you would, obviously, have to check the post before the user.
you could put in a "Block my post" option when posting
Eek! Then we'd be blocking by post instead of by user, and that would interweave a whole different set of logic and database structure to track that.
My envisioned DB structure was simple:
user_id, blocked_poster
And for every post display loop, you check to see if the user's blocked, and then if this post has been requested explicitly.
I am thinking that the display of a post from a blocked user should look different from the display of a normal user. But I have no further ideas.
