I'd like to have the ability to choose on a per-node basis what the maximum number of children it can have. For example, if I have a contest node and a contest_entry node I'd like to see an option on the contest node that says "Maximum contest entries:" and then a text box and a description that says "Leave blank if you do not want a limit.".

Comments

Aran Deltac’s picture

Aran Deltac commented
javanaut’s picture

javanaut commented

If you're handling per-node configuration, you're going to have to store node data in a table somewhere.
If you're going to do that, you might want to make it generic so that other per-node config data can be stored as well.
This begs the question of what data type it should be.
That may point in the direction of the flexinode_data table structure:

+-----------------+------------------+------+-----+---------+-------+
| Field           | Type             | Null | Key | Default | Extra |
+-----------------+------------------+------+-----+---------+-------+
| nid             | int(10) unsigned |      | PRI | 0       |       |
| field_id        | int(10) unsigned |      | PRI | 0       |       |
| textual_data    | mediumtext       |      |     |         |       |
| numeric_data    | int(10) unsigned |      |     | 0       |       |
| serialized_data | mediumtext       |      |     |         |       |
+-----------------+------------------+------+-----+---------+-------+

Just an idea. What did you have in mind?

Aran Deltac’s picture

Aran Deltac commented

I was thinking something along those lines. Althought the flexinode structure is not a very optmized - mediumtext and similar fields tend to be a lot slower for selects. I was envisioning:

nid int unsigned,
name char(32)
value char(255)
index(name(4))

This would be effecient, but not as flexible as the flexinode structure.

Right now all we're talking about is a max_children and a max_children_per_user field. The above table can handle these fields fine. I don't envision ever having any fields that will need more than 255 bytes, do you?

javanaut’s picture

javanaut commented

I don't envision ever having any fields that will need more than 255 bytes, do you?
I suppose predicting the future is half the fun of software development ;)

I think the structure that you have is more in line with what I was thinking of. Just a place to store small, fixed format variables. I suppose you would use the name field as the $node property? (i.e. $node->$name = $value). That seems flexible enough for anything I can think of.

Aran Deltac’s picture

Aran Deltac commented

We're agreed then. The first step is to make some generic functions for setting a custom field on a node and retrieving it. Seems like this could even be a seperate module that handles the ability to assign fields to other nodes. Kinda like a flexinode, but for modules rather than for users. Do you think it is worthwhile to make this a seperate module that relativity depends on? We could make it so that without the additional module that relativity could just fail silently and not provide the node-level features.

Aran Deltac’s picture

Aran Deltac commented

Maybe not... I've not followed the CCK very closely, so who knows, maybe it provides a way to programmatically attach fields to existing nodes (whether flexi or not).

I vote that for now we keep it simple and write the code to attach fields to nodes internally to relativity.module.

javanaut’s picture

javanaut commented

I agree with the latter...considering the currently fluid state of the CCK (or whatever it's going to be called), I'm inclined to just go the simple route for the time being.

BTW, I'd like for you to push the current CVS HEAD code to 4.5 after this feature is done and proves stable. I've been using it with some rigor over the past few days, and it doesn't seem to be breaking (with a few very minor exceptions, patches for which will be coming shortly). That way, we can be free to migrate HEAD code toward the 4.6 drupal core while still maintaining a 4.5 version.

Aran Deltac’s picture

Aran Deltac commented
Assigned: Unassigned » Aran Deltac

Yay. OK. I'll start work on this later this evening. :)