roadmap: Multi Value Field and CCK (discuss)

We'd also noticed that CCK is becoming more capable, and the long term plan is to reduce the recipe module to something that just installs a set of CCK fields for recipes, which could then be customised. We do have a few things left that CCK can't do yet, but feel free to help get CCK improved! In the mean time, this is still useful as-is.

subscribe

>the long term plan is to reduce the recipe module to something that just installs a set of CCK fields for recipes... We do have a few things left that CCK can't do yet

Curious.. what would be "lost" if this were re-done in CCK2 & D6? Will D7 & CCK3 (Fields?) offer what's needed?

As far as I'm aware (not being a CCK expert, and this being from the last time I looked, so may be out of date):
1. Yield - computed from user input & contents of fields (ie. display yield * number of eggs etc)
2. RecipeML export

(Actually last time I looked, that combo field wasn't available either; that's awesome, and a big step towards being able to CCKify recipe.)

Good to know, thanks.

As a long time drupal module developer(DMD:), I'd stay away from CCK at least until it become the norm
for crontrib (which it is not). There are lots of issues with data pre-loading at install time, data migration,
and dependency. I just don't think it is the right tool for every job. It is beautiful for non-programmers who
run sites and want custom functionality which would otherwise be unachievable, but as a developer leveraging
its functionality doesn't give you much. It also ties your normalized db schema in knots(variable schema), and requires a
heavily function oriented API to get data in and out.

I understand that the ingredients list is a pretty tricky bit of code and may or may not work best with CCK. However I can't think of any reasons not to use CCK for the custom text fields (description, instructions, notes, and source). They are just text fields, nothing special about them, except that for now they are hard-coded into the module and therefore very difficult to configure or customise.
I can think of at least 5 reasons to use CCK for these fields:

1. they can be easily customised on the node/edit form (help text, rearrange, title, input filters, WYSIWYG editors, word limits, etc)
2. they can be easily themed on the node view page (using node-recipe.tpl.php, or even just with the CCK display fields tab)
3. fields can be customised with other contributed modules
4. you get views integration out of the box
5. rules integration, also out of the box
6. provides an easy upgrade path for future versions of this module
7. did I mention instant views integration?

@colemanw:
Yes, CCK is great. Really like your numbers 1 and 3.
When CCK is perfect there will be no need at all for the recipe module. You could just add all of the fields that the recipe module
manages, save some kind of CCK install profile and share it on drupal.org.

What currently bugs me about CCK is how some things are implemented (not saying they are impossible):

1. Programmatic adding/removing CCK fields at module install/uninstall
2. How users/modules can modify fields and the underlying data structure. Right now I can write bulk import and export functions and know the field names and how/where they are stored.
3. Nothing stops users from adding extra fields right now (yes removing existing fields would be a pain in the form_alters:).
4. Until we can migration all the fields, it is easier to keep all the fields using the same api.

And the biggest gotcha of them all:

• drupal 6.0, February 13, 2008
• views 6.x-2.0, October 17, 2008
• cck 6.x-2.0, November 5, 2008

I'm not a fan of any hard dependencies. And yes, I know there were -alphas, -betas, and -rcs in there as well.
But where we can add optional dependencies to boost functionality, that's great.

I think there is a way to programmatically add CCK fields, but I don't know it. Under Drupal 6, this would create a hard dependency on CCK (and I don't like that either) but as far as dependencies go, CCK is pretty common. I'd suspect that the only sites not using ImageField on Recipes (and therefore using CCK) are the sites who don't know CCK integration is possible.

In Drupal v7, the parts needed of CCK are now part of core. So this would be a valid change for D7. If there are not bad side effects to Recipe, under D7 we can look at making some of the text fields as CCK fields.

What would hold this change back is the fact that it's a fair amount of work, especially data migration (previous installs). If more people want this change (which comes at the expense of other development) and speak up, then it is more likely to happen. Now if someone steps up with a comprehensive patch to do this, it would be MOST generous (but I doubt anyone would want to do so and target D6). I haven't looked at what amount of work this entails, so it's currently a low priority.

John - The way this was suggested, Views wouldn't be a hard dependency at all (not under D6 or D7).
CCK displays CCK fields just fine... Views not required unless you want to customize the data presentation.

colemanw - Views integration exists now in the -dev release, and it works on the fields you mention. Try it. The part that is difficult to handle in views is the 1:N relationships of ingredient details (think 1:N duplicated fields in a SQL outer join). My work on this area has stalled recently, unfortunately.

FYI - There's a Recipe 1.2 release coming soon. I don't know what comes next as I have not been contributing for the last month or so. But sometime soon, a Drupal 7 branch occurs. After that gets out there, these things are a little easier to develop against Drupal 7 (some of the dependency issues do go away).

Closing old issues. Any future work on this topic would concern D7 fields.

Closing old issues. Any future work on this topic would concern D7 fields.