[development] CCK field generation confusion (and how to solve)
ber at webschuur.com
Tue Oct 10 14:52:03 UTC 2006
I have been fighting CCK fields for the last two days again. My general
conclusion already was that it is a little too hard to grok, so let us get
Because it is too hard to grok. Looking closer at the field that are there,
you will notice that the developers were:
a) inconsistent. Very inconsistent. Every module with fields is completely
b) using fields where they should have used widgets. And using widgets where
they should have used fields.
c) seem to be overly confused about the 'multiple' thing.
Documentation. This is a catch22, because how much I would love to make docs,
I am too unfamiliar with CCK to write docs.
Even some sketchy notes by/from the original designers (why multiple, what was
the idea behind fields vs widgets) can help. Are they anywhere?
And more technical:
Documentation can help us solve some of the issues. But even with docs and
examples, this material is very hard to grok. The workflow is like spaghetti,
the hooks, using call-by-refs trace back up-to 5(!) hook calls deep!
(meaning: hook_foo calls hook_bar, which calls hook_baz etc, 5 of them is the
most I counted).
Call by reference:
Either all of the stuff should be call by ref in all hooks at all points. Or
none. Not have $node as called by ref in some $ops (load) but not in others
Hooks vs FAPI.
Because the general Drupal-way seems to be towards _altering of FAPI forms,
instead of the 'old' hook mechanism, CCK uses many hooks. To alter forms. But
not everywhere. These CCK hooks are well documented already, but when it
mixes with form alters, you get a messy spaghetti-bowl again. I'd say: either
_alters all over the place, or hooks, but never both. Hence I suggest to drop
the hook_*() $op == 'form' in favour of form_alters all trough CCK.
Fields widgets and the rest.
This is confusing. When I read peoples fields-modules my general idea is that
no-one really groks this. Eventhough I understand the database architecture
behind it , I still think that
a) the names are confusing.
b) the associated hook ops are badly named.
Hence I suggest to take the widgets out of CCK entirely, and stick them in a
widget_library.module. CCK-field modules can pick widgets from that library.
If they need additional widgets, then they can add them to the library. This
way we can do away with the current 'widgets and fields' confusion. And we
can enforce people to think slightly better about their fields vs their
widgets. Right now, nearly all of the modules with CCK fields have
widgets-who-validate-field-data, or fields-whom-dictate-widgets.
An additional benefit is that any module can easily re-use fancy widgets
without needing the whole of CCK.
Another benefit, is that the amount of code that needs to be changed can be
minimised. A big downside is the dependency of CCK on the
There are a lot of users, but very few developers for CCK. The main reason,
IMO is the very steep learning curve of CCK development. (see above)
But I think that enough people are willing to contribute if CCK were a little
If we can agree on the abovementioned ideas, or provide better ones, then I
hope we can get this started with some patches and issues right away.
[ Bèr Kessels | Drupal services www.webschuur.com ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20061010/ac3c1537/attachment.pgp
More information about the development