Wedge

Not if you want a poor man's helpdesk, for example... There are plenty of cases where you might want to allow multiple users but not everyone to see a given topic.

Yup, only at post saving time.

OK, getting down to brass tacks (I can wait on the above post for a while, not so bothered by that), I figured all the way along that I'd have to store it somehow and parse it meaningfully.

What I'm ultimately thinking is that I'm going to store the list of rules in an XML block, inside the DB. Now before anyone shouts how inefficient that is, consider it from my perspective.

It's clean to parse, it's not restricting the content to linear columns (and given the inclusive/exclusive nature of things, that's a good thing) and it means I can cleanly delineate and/or clauses in exceptions and rules without brackets which while human readable, do make it a lot more complex to process internally.

Performance of handling XML isn't bad actually, probably better than I'd be able to do with a custom language parser all told.

This is just off the cuff but covers what I'm thinking of. (It's not intended to be user-visible but I guess it could be for 'pro' users. I don't really intend to build a pro interface exactly. I'd rather build one great interface and be done with it, the idea is that this is internal use only. It probably wouldn't even be indented/line-broken normally.)


This would make all the new posts in board 1 be moderated, except for admins.


New topics will be moderated if the board is id 10, OR if the user has less than 10 posts. That's why there's the criteria tag, to contain all the elements of a clause, because you could do things like this:


This way, you'd post moderate any new topic created by a user if it's in board 1, OR if they have more than 40% warning, except in board 10. Perhaps that's a banned board, or a test board or similar. Either way, it allows you to create AND clauses within a rule. (This one is: (warning > 40 && board != 10) || board = 1, expressed in code.)

Hmm, now I look at it, I'm sort of wondering about writing it in PHP-like code, but I just feel that it would be easier to manipulate done in XML than it would in some kind of code. This is, after all, extensible (and suits how I'm envisaging plugins would interact though this too)

Thoughts?

*nods* Sounds like a plan to me :)

Though at some point the preparser needs to be gutted to actually examine the post with respect to the tag's definitions, rather than relying on its own defined rules (so that table->tr->td isn't defined through some esoteric regexp but because that's how the bbc rules define it - which means it becomes possible to add attributes, or even, dare I suggest a th tag)

Where does that code run, exactly?

(Haven't looked at the commit yet)

Generally, it's not a huge deal because the parser will close any tags at the end (so that the tag endings will be output correctly) but for code tags, processing is quite a bit different in the bowels of the bbc parser, because the content is actually split by code tag, and the loop can safely deal with extra /code closers but it'll get very upset if there's more openers than closers.

I think it would potentially be confusing to treat it as a draft, but personal posts I can see the logic of, e.g. blog post with very personal details.

Re moderation, I think I'm going to have to leave it for now and come back to it.

Also, one thing that I'd address: how many people are voting on what sounds useful vs what they would actually use if it were available...?