[development] object.module (was nodify.module idea: 'everything is a node')

[Bèr Kessels]

I don't like the idea of storing a 'thing' in one table alone. Its not good 
for performance and horrible when you want to normalise your data. 

Therefore, I think its a much better idea to go the Active Records route: 
Define good defaults/standards and provide APIs that can pull information 
from these standardised tables: 

drupal_object_load('comment', array('id' => 450));
or
drupal_object_load('term', array('author' => 'Joe', 'created_at' 
=> '12-01-2007'));

Off course we need to elaborate on all the details and the hows, whens and 
ifs. But the idea is simple: 
 you define what 'object' to grab. the drupal_object_load will then:
 1) look for a $object_name. '_load' function. If exists it will leave the 
loading to that function.
 2) if not exists it will simply try to grab a record from the {$object_name} 
table.

Obviously we need to stick in some more hooks (to let other modules change the 
objects before or after they are loaded etc)


Op zondag 21 januari 2007 03:15, schreef Jeremy Epstein:
> - body text (filtered)
> - commenting
> - versioning
> - adding CCK fields
> - displaying lists with views
> - metadata (e.g. author, created/updated time, published, promoted)
> - hierarchical (i.e. parent-child) relationships
> - display of TOC and prev/next links (for hierarchical nodes/categories)
> - tagging (i.e. ability to tag categories with other categories,
> rather than just tagging nodes)
> - automatic URL generation with pathauto
> - more powerful theming, e.g. per-content-type theming, CCK field theming

Two more fields, coming from active records (Ruby on Rails) bein *extremely* 
useful. Especially because in Rails, the Rails core inserts/updates them for 
you, provided you named them correct:
  updated_at
  created_at
 
Furthermore Rails has a very nice way of handling foreign keys (re: that other 
discussion) also on none-FK-enabled DB engines, by using standardised table 
and column names (note the plural and singular!)

N-to-N
tables: terms, nodes. Join table must then be called nodes_terms
nodes_terms has columns | id (private key) | node_id | term_id |
Active record (Rails) will then sort out the joins for you! without any 
programming, using only one statement, by the developer. Something like this 
could be achieved in a simpler, Drupal-way!?

1-N
tables: comments, nodes. No join table.
comments has, in addition to its private columns one more: node_id.
Active record will then load the node with id node_id whenever you load a 
certain comment.

And please, lets not start about wether or not you like RoR, but instead focus 
on simplifying this idea and boiling it down until it reaches a Drupal-worthy 
concept? 
Maybe we should or could have a look at how hooks can solve parts from this? 
And if it is acutally a Drupal-worthy concept to start with?

Bèr
-- 
Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: 
www.sympal.nl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20070122/91030004/attachment-0001.pgp