Provide example implementation for hook_view()

It would be perfectly reasonable to add an example of this, probably in NodeAPI Example. Add some info to the $node->content just as illustrated in http://api.drupal.org/api/drupal/modules%21node%21node.api.php/function/...

@ray: the function theme_example_node(in the patch that follows) should output a more reasonable way to display the information. I couldnt think of any, may be this requires some work

Still some work to be done on this.

1. You implemented node_content_view(), but hook_view() should be node_example_view().
2. Please make sure to explain that hook_view() is quite unusual, and that a person would normally use hook_node_view(), which does the same purpose. I suspect that hook_view() is a relic from an earlier version of Drupal that just didn't quite get dropped.
3. For clarity, please use 'content_type' instead of 'type' in your theme function.
4. Don't forget to add a test.

Thanks for all your effort and contribution on Examples!

There's a more fundamental problem with this example: hook_view() is only invoked on the module that defines the node type. That is, it will only run for node types defined in the module's implementation of hook_node_info().

And that's where the trouble starts, because there is no node_example_node_info(): the node_example node type is created in node_example_install() instead, so hook_view() won't ever be invoked.

I'm not sure how best to address this. We could re-work the module to define the node type in hook_node_info() instead of creating it in hook_install(), but I'm not sure how easy it is to create default fields and such when done this way.

@BrockBoland, I kind of suspect that hook_view() is just a dinosaur. What do you think?

@rfay, I don't know about that: I think it's still worth demonstrating. In most cases where a module is defining its own content type, its because it will need some custom functionality beyond the addition of fields (which, of course, would not require anything in a hook_view() implementation). Take poll for example: it makes sense for poll_view() to build out the view of a poll, since that hook will run before hook_node_view() is invoked on other modules. This ensures that $node->content has been built out with the poll form or results before other modules try to act on it. If poll.module implemented poll_node_view() instead of poll_view(), another module with a lower weight could try to modify the poll in its own hook_node_view() implementation, before the poll module had actually initialized that content.

I know it's not a common use case, and poll is really the only example I can think of at the moment, but I think it would be worth including an example.

hook_view() would properly be demonstrated in node_example, since it implements a node type.

However, node_example doesn't implement a node type the right way. :-) It doesn't use hook_node_info(), using node_type_save() in the install phase instead. Not best practices in D7 for a bunch of reasons. I'll make a new issue for that.

Anyway, hook_view() is pretty much a D6 throwback, and also pretty much deprecated, I'd say. Showing how to implement a pseudo-field would be better.

I'm calling this closed.

If anyone wants to pick it up, go right ahead.