[development] The future of hook_node_info()
Larry Garfield
larry at garfieldtech.com
Thu May 21 13:57:37 UTC 2009
On Thursday 21 May 2009 7:54:03 am Arancaytar Ilyaran wrote:
> Will hook_node_info() eventually die entirely, in favor of working on
> nodes centrally handled by node.module? Should it?
>
> Thanks for reading all the way, :)
>
> -Aran
Potentially, but there are two key things that need to happen first:
1) There are still things that can only be done by a custom-defined node in its
own module. The most notable is hook_access(), which still must be defined by
the declaring module if you want permissions that differ even ever so slightly
from what node module defaults to. That needs to get ripped out and made
pluggable per-type, and stackable. There has bee discussion on how to do this
well back in Szeged, but unfortunately no one who was at that BoF has had the
spare mental cycles to work on it. :-( (If you want to volunteer, let me know
and I'll try to help.) I think there's a few others items that must be done
by the declaring module still, but I can't recall them off the top of my head.
2) Easy programmatic creation of new nodes. Some modules need to have custom
behavior that comes with their nodes. Poll is a text-book example. For
hook_node_info() to go away, it would need to be replaced by a *good*, *easy
to use*, *flexible* way to declare a node type and additional behavior (eg,
Fields) in a way that could be easily imported on module installation;
patterns.module looks like it could be a step in that direction (I understand
it's in the process of moving away from doing everything via drupal_execute(),
which is good), but there are other efforts along similar lines.
If you want to kill hook_node_info(), tackle one of those problems first. :-)
--
Larry Garfield
larry at garfieldtech.com
More information about the development
mailing list