[development] Configurable content types in core

[Bèr Kessels]

Thank you for the time! :)

Op maandag 28 augustus 2006 20:32, schreef Syscrusher:
> On Wednesday 09 August 2006 07:23, Bèr Kessels wrote:
> > And -for once- come up with a good database model (entity relation
> > diagram) before  the code/patch?
> >
> > If you want to do something this big good, your datamodel must be good.
> > And to design a complex datamodel, simple PHP code won't cut it.
>
> A big +1 from here! Code can be refactored or completely rewritten much
> more easily than a data model can be redesigned. Let's take the time to get
> it right from the start.

I have upgraded the post, and tried to explain all the items a bit better. I 
also redrew the ERD in UML, so that I could share the drawing as SVG and as 
XMI. Feel free to take the erd and make it into something better. :)

> > Because of this, I have just put my initial thoughs online with the ERD.
> > As I state in the small description, I am clueless when it comes t
> > drawing such diagrams. :)
> >
> >   http://webschuur.com/node/643
>
> I think this model (albeit an early draft, as you say) is fundamentally
> sound in its semantics. Just out of curiosity, what are the "node
> characteristics" to which you refer, and what is the "id" field in that
> entity? If this is the actual data for a node, then you may need the node
> ID plus the field ID as keys rather than just a single ID key. Or am I
> reading it wrong?

I explained node_characteristics in the refactored ERD a bit better. 
It is, in essence what we now do in hook_node_info, it describes what code 
or "stuff" handles that node type. My ERD/model, however, allows us to let 
many modules handle a node. We currently have two mechanisms, both don't 
allow user_interaction: hook_insert/update/etc and hook_nodeapi. By 
refactoring the model a little and by pulling the relation node_type - 
node_handler into the database, we can allow a) a standard UI to handle the 
node (uploads, images, products, categories, taxonomy, etc management from 
one interface) b) many modules to act on the lifecycle of a node, while 
improving performance! (we know beforehand what modules want to interact on 
node_load, e.g.)

Also note that a lot of "stuff" is still missing. My nodes don't know if they 
are published (table node_visibility) nor who authored and edited them 
(node_author table) they don't track dates (additional columns in node 
table). and they don't have revisions (node_revisions) etc.

I also have no clue how to handle this in reality. Drupal's patch-system does 
not allow for such a great overhaul, so maybe we should first agree on a new 
theoretically/ideal ERD, then chop that up into mini-tasks?

Bèr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20060829/cf031f61/attachment.pgp