[development] CCK in Drupal 6

[Darrel O'Pry]

On Tue, 2007-02-06 at 00:11 -0800, Neil Drumm wrote:
> Larry Garfield wrote:
> > On Tuesday 06 February 2007 12:08 am, Neil Drumm wrote:
> >> Dries Buytaert wrote:
> >>> On 02 Feb 2007, at 13:10, Ray Zimmerman wrote:
> >>>>> Getting more of CCK in core would be great.  Once more of CCK is in
> >>>>> core, we can talk again about profiles.  Now, where are the CCK
> >>>>> patches?  I haven't seen any yet. :-)
> >>>> Since getting more of CCK into core is, presumably, not a matter of
> >>>> simply copying the contrib CCK, I was wondering if anyone has laid out
> >>>> what exactly needs to be done? I'm not in a position to propose one,
> >>>> but it seems a prioritized task list would be the place to start.
> >>> Good question.  In fact, after months of bugfixing, I could use an
> >>> update myself.  Hopefully CCK-wranglers like Eaton, Jaza, KarenS and
> >>> friends might be able to lay out a bit of a plan ...
> >> The big thing that is left is field management.
> >>
> >> I'd like to see:
> >> - No modules added. I don't think this is a feature that would want to
> >> be disabled at the system-level. There are other ways to organize code
> >> without adding more modules.
> >> - A generic solution that profiles fields work with.
> > 
> > Which then begs the question, if one were to simply rip the field management 
> > parts out of content.module, tuck them into node.module, and polish a bit, 
> > what would be left to do?
> 
> Thats one option. Merging APIs with profile and making it generic can 
> certainly happen after node fields are working. I'm not sure that would 
> be so simple, the "polish a bit" step might take a bit of work.

The polish bit is quite a bit of work. Things that need shining...

- Simplify CCK API's. 
  - _info hooks could easily be rolled into the _settings hook.

  - hook_widget could lose most of its ops to FormAPI

  - formatters need some type of settings form, maybe not now but
    sometime. I've been running into many cases with imagefield where 
    people want more and more options for formatters.

  - leverage FormAPI better for all forms.

- Field Grouping code needs TLC. It looked pretty hairy last time I
looked at it. It's a really cool feature, but I'm not certain it belongs
in CCK. It's usefulness has a much wider scope.

- Getting per field access control right.

- Multivalue support needs love. Values are often left in the database
after all values of multivalues fields are deleted. It causes some chaos
and sanity checks in places they shouldn't be necessary.


Things we should just do for posterity's sake:
- Security Review
- Usability and Copy Review.
- Review Inline Documentation.

> > (For me it's value-add fields rather than value-add form primitives, which I 
> > imagine would involve hook_elements and hook_widget merging or becoming more 
> > closely linked or something, but that's just my speculation based on banging 
> > my head against a CCK field module for the past few days. <g>)
> 
> That might be a good concept too.

The idea that Eaton and I had along these lines was to make
hook_widget_settings and interface for relating form_elements to fields
and providing set of settings for that element. This could eliminate the
callback in CCK, but would require learning how to construct form
elements in order to create CCK fields for developers. The same could
probably be done for output via formatters as output rendering via
FormAPI matures. 

I'm sure there are better ideas, but I have been out of the loop for a
bit. I'm sure Karen, Yched, Eaton, and Jaza have some ideas as well.
Ber probably has some ideas from his work and experience with Flexinode
we should listen to. I think it would be cool if plenty of generally
intelligent bi-peds that operate computers actually look over the code
and ask a lot of whys and why nots.