per-instance required status for fields
ray007 - March 7, 2007 - 14:13
| Project: | Content Construction Kit (CCK) |
| Version: | 6.x-1.x-dev |
| Component: | General |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | by design |
Jump to:
Description
I think it would make sense to move the flag for a field being mandatory from the field-definition to the field instance declaration.
I.e. I have 2 content-types on my site that would like to use the same nodereference field, but only in 1 it would be mandatory and optional in the other.
Or is there some option to override this flag in the field-instance?
I guess I could make the same argument for the "multiple" flag, but i don't need that now ;-)
#1
The 'multiple' flag must remain as a field declaration because it impacts the database structure which can't be different for different instances of the field.
It might be possible to move the 'required' flag to the instance, but we need to think through all possible ramifications of that since there are lots of places in this code and in contrib code that assume that is set on the field rather than the widget. It has the potential to break contrib modules, so I'd be inclined not to make the change unless there is a really compelling reason to create all that havoc. I can tell you for sure that it will break the Date module, which would have to add special handling to figure out what version of the content module is being used so it would know whether to look for the required flag in the field or the widget.
#2
Ouch.
And here I thought that's just under the hood and the modules using the cck-api won't even notice ...
If you know about another way, to build a view with a filter for a field, that's required in one type and optional in another, I'm all ears ...
#3
'Multiple' attribute in field instances is definitely a no-go.
And yes, I'd tend to be extremely cautious on the question of 'required' - I'd even say if it possibly breaks contrib fields, then it's a no-go as well...
#4
May I suggest that CCK take the same position as core with respect to backwards compatibility. Each new version of CCK can break with the past. Patch level releases cannot. So CCK 5.2 could break from the current 5-1. you probably are planning that, but i notice in various issues a strong allegiance to not breaking contrib modules so i just remind here. those contrib modules are welcome to use .install files to update schema and code, just like core.
#5
Yes, that's what I meant actually, but I should have been clearer.
So : 'required' as a field-instance property : maybe one day, not before CCK 2.0 (if any).
Same goes for most of the issues where this 'compatibility allegiance' is shown.
The thing is we're not clear yet whether the next 'big step' for CCK will be FAPI3-in-core, CCK2-in-core, CCK2-in-contrib :-)
#6
and updtating title and status accordingly :-)
#7
I've been thinking a bit more about this and the broader issue of 'not breaking things'. One thing that occurs to me is that in the next version, whatever that may be, we should perhaps have a function that returns values like this rather than having field modules expecting to find it in a particular place. Then field and contrib modules would no longer refer to $field['required'] or $field['widget']['required'] but instead use a function like content_value('required', $field), or some such, so that core would be free to change the db structure as needed without any worry about what it does to contribs.
I have been taking that approach more and more with the display, for instance. I'm telling everyone to use content_format() instead of $node->field_name[0]['view'] so we are not tied to any particular array structure.
#8
Bumping this since I've found myself wanting it a couple of times, although I'm not sure there's a clean way for it to be done. Good time to decide anyway.
#9
The same issue was marked as "by design" for 6.x-2.x here:
#377654: Required should be able to be different for each node type