[development] Configurable content types in core
ber at webschuur.com
Tue Aug 29 09:30:56 UTC 2006
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
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20060829/cf031f61/attachment.pgp
More information about the development