Active
Project:
Multifield
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Issue tags:
Reporter:
Created:
4 Apr 2014 at 02:37 UTC
Updated:
28 Jul 2014 at 21:57 UTC
Jump to comment: Most recent
It would be nice if one could specify the conditions by which a multifield 'is empty'.
Basically, Im using multifield to group a bunch of fields together to create a 'tracked url' field that acts similar to the link field.
I have five fields defined: the analytics category, action, and event, along with the link text and URL.
So, for my purposes, I set some of those fields to defaults, however if the URL field is empty, I would like the whole multifield to be treated as empty (i.e. hook_field_is_empty() would return true if the URL field is empty).
Maybe a setting in multifield_form_field_ui_field_edit_form_alter() that allows us to say "use this field in determining emptyness" or "exclude from emptyness checks" - but with clearer wording.
Comments
Comment #1
dave reidWhat if we used the 'required' property from the subfield instances? In this case you'd mark the URL field as the required field?
Comment #2
MixologicThats just the thing, taken as a whole, the multifields themselves are definitely optional. Maybe if there was a way to mark the entire multifield as optional/required, and to use the subfields required property to determine emptiness (such that marking a subfield as required didnt actually make it a required field on the parent entity).
However, that seems slightly contorted, and might require a lot of documentation to explain that convention...
Comment #3
dave reidYou can mark a multifield itself as a grouping required or not when you add it as a field to say, nodes. I think it makes a lot of sense to re-use the required logic for the subfields to determine if a group is empty or not. I'll mull it over.
Comment #4
JackVegas commentedI think you could create the desired behaviour using
https://drupal.org/project/conditional_fields
Comment #5
MixologicConditional fields works with permissions. This isnt whether or not a user can see the field, its whether or not a user is required to enter the data in the fields. And its a sort of data modeling conundrum. You can 'require' the multifield, or you can 'require' the subfields. If the multifield is required, does that mean *all* the subfields are also required? What if the multifield is optional?
Conditional fields would just hide them entirely.
Comment #6
JackVegas commentedI did not test Conditional Fields in its entirety but there are options to change whether a field is required based on another fields value. And also hiding a required field seems to make it optional. I don't know if this has any impact on the result of an emptiness check but I think you might want to check that. It seems reasonable to assume that entirely-hidden, i.e. non-existent fields are empty by default.
Regarding the semantics of *required*: I would approach this by clarifying what a multifield is. On the one hand it could be just a preset of fields that may be plugged into an entity at once. On the other hand it could be a way of defining new field types by composition. Then requiring a subfield or not is a validation criterion to check composition-values against. As with any other optional field you either leave it empty or fill it in a valid way. That's just how fields work. If there's something than its at least valid :)
@Dave Reid: Could you please comment on what a multifield is intended to be? A field-collection preset or a composition field-type?
Comment #7
MixologicI dont have specifics, but I do remember that I did try and use conditional fields for this, and it had a hard time with the way multifield handles things. I looked under the hood of conditional fields, found dragons and landmines, and decided it wasn't worth it to make it work together. Hence this report.
The way that multifield is implemented is as an attached dataset, that can have more than one instance of that dataset attached to the parent entity (multi value multifields).
In that sense its int just a preset of fields that get plugged into an entity (kinda like you would extend an object with additional properties i.e. a mixin of fields) But this is more like a subordinate entity, without actually using the entity api or entity references to be a subordinate entity.
Comment #8
dave reid