[development] CCK field generation confusion (and how to solve)

[Bèr Kessels]

Hi,

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 
that solved.

Why? 
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 
different.  
 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.

How?
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 
(insert). 

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 
widget_library.module.

Who?
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 
more accessible. 
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
-- 
 [ Bèr Kessels | Drupal services www.webschuur.com ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20061010/ac3c1537/attachment.pgp