[development] The future of hook_node_info()

[Chris Johnson]

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
<news at unleashedmind.com> 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
>
>