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.


KarenS’s picture

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.

yched’s picture

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
  - ...
moshe weitzman’s picture

Title: Weight should be context setting » Introduce 'display' as a way to group and reuse instance and formatter settings.

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.

KarenS’s picture

yched’s picture

Component: field system » field_ui.module

Probably far fetched for D7, but belongs to field_ui now.

andypost’s picture

Suppose this issue should be marked as closed(fixed)

yched’s picture

Version: 7.x-dev » 8.x-dev

Still on my hitlist for d8

Stalski’s picture


Was not aware of this issue so I thought about this as well ...
I came up with the same reasoning as in #2. So generally A display object with its own storage is the biggest request here.
The thing I did not have was the link between view mode and display (in my reasoning the view mode == display, but that would not work properly).
So basically #2 is a great solution imo. If we go that way, it's all about responsibilities.

What I also think is that view modes should be shipped in core as they are already introduced in core. Views in core is just another major decision maker on the view modes in core.

Other remarks following #2:
- All contribs adding stuff to the field UI screen (like fieldgroup, ds, ...) would need to cleanup the saved configurations for all view modes / entities. This is not that hard.
- Field formatters which come from contributed modules is a hard problem, especially since the formatter is not there anymore and should be set on "default", but what is default ... . In some cases this is how it was configured before the contrib providing the formatter came along. So this is something to think about.
- This makes it also possible to have a different Display object, E.g. a module comes around who leverages a new FIELD UI, very much as we know the page manager. This can be display suite or some other module providing the "advanced layout".
The question then is 1) Do we overwrite the original display settings so the reading code stays the same, or 2) Do we need a simple bridge that just reads out the advanced display settings. (In this latter case we can just disable the advanced layout and everything is back as it was).

Just some thoughts. Let me know if some decisions already have been made. I'll help everywhere I can (DrupalCon Munich gave me this very positive boost)

Stalski’s picture

Referencing #1812720: Implement the new panels-ish controller [it's a good purple]. Imo they can be developed totally separate from each other, but the information found there is interesting for this issue.

swentel’s picture

Status: Active » Closed (duplicate)