Posted by KarenS on February 1, 2009 at 1:55pm
Jump to:
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | field_ui.module |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
Weight is now an instance setting, which is mostly a holdover from the D6 version of CCK. It should probably be a context setting so that it can be different in forms and in various other contexts. And 'form' should maybe be one of the contexts in the display array.
Comments
#1
More thoughts:
- The form weight should be a widget setting, since it's only for the form.
- We could have a top-level instance weight, as we do now, and instead of explicitly setting a weight for the form and each context, instead assume they will all be the same unless they are overridden, so we would add a 'weight_override' setting to the widget and each context instead of a 'weight' for each. If there is no override, we use the default weight.
- We should change the way that 'weight' works now and have the Field module use the weight from the correct context when it displays the field and creates the form. That way context-sensitive weights could be implemented immediately by modules using the API. And CCK can start out by using the same weight for everything, as it does now, and allow users to set different weights later when the UI is improved.
#2
Weight should definitely be 'by context' - including 'forms'.
As you point out, this raises the issue of the explosion of weights you need to define for each 'build mode' (full, teaser, rss, search index, 3rd party build modes, user-defined build modes, etc...). This applies to display options and formatter settings too, for that matter.
Here's the big plan I had in mind :
- weights and display settings are not tied to 'build modes', but to 'displays'.
- a 'display' is a collection of field ordering and display settings (formatter + settings, label display mode...), assigned to a given bundle. Each bundle has its collections of displays.
- fieldgroups would also be 'by display' : you can have different grouping on forms and on various displays.
- 'build modes' are assigned to displays : 'teaser' uses display 1, 'full node' and 'rss' use display 2, etc
- each bundle has a 'default display' : weights and display settings that are used for all build modes that do not specify otherwise (or for instance because the 'build mode' is exposed by a module that's just been enabled). Users can add additional displays and assign to fit their needs.
This IMO gives the best flexibility while keeping a manageable UI experience (much simpler than the one we currently have) :
you can specify that 'article' nodes will use specific display settings for teaser, and the same settings for all other modes, and something different for 'page' nodes.
Now, how do we get there ?
I think core can live with only the notion of 'default display' : *one* set of display settings used for all build modes :
- CCK brings the notion of additional displays (and the UI and settings storage that goes with it).
- When a field is about to be displayed, field_default_view() lets contrib modules hand the display settings that must be used.
This means more or less what you propose above, except for the 'weight_override' part :
$instance['widget'] has a 'weight' property that's used for forms
$instance['display'] is not anymore :
- (context_1)- label
- exclude
- type
- settings
- ...
- (context 2)
- ...
but just :
- label- *weight*
- exclude
- type
- settings
- ...
#3
Brilliant idea. I think TinyMCE has a similar notion of a settings group that gets reused. Or at least it did a few years ago.
#4
Cross reference to http://groups.drupal.org/node/23545.
#5
Probably far fetched for D7, but belongs to field_ui now.
#6
Suppose this issue should be marked as closed(fixed)
#7
Still on my hitlist for d8