In the heat of the moment, it seems that the further in I go the less I like the experience of learning Drupal 7.
A Drupal fundamental is to treat every piece of content as an instance of a single basic type (a Node – although apparently Entity is the new term :-S ). Having established the fundamental, Drupal adds nuance by making the Node an abstraction, providing specialised versions as the containers users will actually fill with content, and allowing users to create their own similarly specialised Nodes to store content that has different qualities.
Given the emphasis on standardisation at Node level rather than any lower, and the fact that real-world examples of Nodes can have arbitrary amounts of arbitrarily-named subsidiary data attached to them, it is essential to be able to look for data in each Node in a standardised and abstracted way. Otherwise the rationale for the overarching system disappears.
In practice it seems as if public modules have introduced increasingly complex Node types to perform specialised tasks in total isolation from one another. These modules have hard-coded subsidiary fields referenced directly by the functions that manipulate the data in the fields. Ironic given that all are supposed to derive from a common parent which provides the bulk of their functionality. I don’t want to do that: instead I want to enhance what any type of node can do if a user has put certain information into certain fields for that node.
I am having a lot of trouble using the Fields API to find out quickly and cleanly which fields are attached to nodes as I load them and from that to discover the content of each field in each node. This ought to be extremely simple for implementation developers. The alternative, which is to list and access fields by reading the array of data that belongs to each Node, is low-level, complex and hence inappropriate as much as inconvenient. It’s miles away from the sophistication I find in the functions which are in the API, and I can’t help feeling I am missing something very obvious.
There is some documentation, but it gets more opaque the closer I get to the tasks I want to be able to achieve and I feel that I’m working against the grain of the system. To make things worse, there is a depressingly incoherent tutorial in the API documentation which seems to capture the general lack of clarity about Fields. All in all, a little downbeat today.