Maybe we actually need node objects AND generic, stripped-down Drupal objects. All of the extra "baggage" that comes along with node types is actually sometimes very beneficial and powerful, making it much easier to do some things. At other times, it's completely in the way -- hence, I've sometimes created completely new objects in my modules without using nodes at all.
Just as a wild idea which might have some potential use -- maybe take a look at how the file framework handles its objects (http://drupal.org/project/fileframework). On Thu, May 21, 2009 at 11:50 AM, Daniel F. Kudwien <[email protected]> wrote: >> In the "more": nodes have revisions. They have a body in the >> node_revisions table. > > Yes, and AFAIK, there is already an effort to turn node_revisions into field > revisions, eliminating node_revisions. But then again, who says that a > contrib module implementing private messages (or whatever) has no use for > revisions? > >> What you are proposing is to implement a more generic "Drupal >> Object", of which the Node as we know it would be a >> particular version. That makes a lot of sense, and would >> allow us to also properly implement "set based lazy-loading" one day. > > I'm not sure whether I would go that far. Was rather thinking that re-using > the schema of {node} along with the API for nodes would dramatically simplify > a lot of contrib modules and would "automatically" introduce the flexibility > and customizability of nodes. - Which also results in a much nicer DX > experience, because you wouldn't have to lookup, learn, and hook into > countless of node-alike implementations. > > But, most probably, you are right. :) > > sun > >
