[development] Moderation bit behavior
merlin at logrus.com
Wed Jul 5 16:13:48 UTC 2006
Gerhard Killesreiter wrote:
> Mark Fredrickson wrote:
>> On the subject of bits on nodes, I would advocate for the least
>> number of hard wired fields as possible. Hardwired data conflicts
>> with user configurable systems and makes administration harder and
>> more confusing for end users. Instead, I would advocate for
>> dynamically added data (from modules) where needed.
>> In more specific terms, let me argue for removing a large portion of
>> the current node object (feel free to disagree):
>> From the node table:
>> nid - keep
>> vid - keep
>> type - keep
>> title - remove. Titles should be set by node modules (and stored
>> where the body and teaser are), not stored in the node table.
> This was a design decision. We often only need the title of a node
> (for link lists for example). If we do a join on the node_revisions
> table, we lose a lot of time. We are contemplating to add the author's
> name for the same reason (save join on user table).
>> uid - keep
>> status - remove. Let a module like workflow control the state of the
>> node. Or, don't have a state. Let the admin decide. Node_access is a
>> better solution than an all or nothing published state, in my opinion.
>> created - keep.
>> changed - keep
>> comment - remove. Why would I want this data if I don't allow
>> comments? Spareness should be avoided if we can help it.
>> promote - remove. Let's move nodequeue into core and make a default
>> "front page" queue. This more extensible.
>> moderate - remove. As this thread shows, no one is sure exactly what
>> moderate should do. Let a moderation system control node moderation.
>> sticky - remove. Again, let the nodequeue system decide what is first
>> in the order.
> I'd be in favour of a more flexible bitfield instead of all the single
I'd be in favor of something along these lines:
node_flag('moderate') -- returns the name of the flag used for
'moderate' or NULL if there isn't one.
node_flag_register('moderate') -- register the flag during .install,
returns the real fieldname. Returns NULL if no flags are available.
node_flag_list() -- return an array of all existing flags
Modules can then register their flags which are directly put in the node
table. We can pick some number of these; we could add a method to add
Queries simply use node_flag('moderate') instead of 'moderate' if they
care about it. They never need to know the field's true name.
Cons: database names won't be transparent because it will just be
'flag1', 'flag2' or whatever, and some kind of translation may need to
be done for things that look at a node as a whole. Also, 'flag1' on one
Drupal install will have a completely different meaning from 'flag1' on
another. I think both of these cons are quite minor; they allow us to
kind of do away with the moderate flag without actually doing away with
it. Modules which need to set flags can.
More information about the development