OK. Ace module. The ability to give the end user a UI to choose & configure a view to embed on an entity is brill =).

However, in practice, there are a whole bunch of ways that I may want to customize the widget I give to my users for configuring the view. Perhaps I want to add a couple of custom form elements which override certain view settings before passing to off to be rendered? Or perhaps one day a module will come along which allows us to embed the views exposed filters on the entity edit form rather than the entity view page. That would be cool!

Ninety percent of this functionality can be currently added with custom widgets & formatters (or altering the current ones). But the problem is, if a contrib module tries to add something to the viewreference widget (e.g. a "Override items per page" textbox), then there is no good place for it to store its values for the extra config inside the field value. This is because the current field schema only has two columns: view_id & arguments, neither of which is appropriate for extra custom data.

I am needing to make such a customized viewreference widget for a current project and I feel very strongly that if my field is referencing a view it should use the one, canonical, meaningful 'viewreference' field type (i.e. that provided by this module =p). However without some sort of change to viewreference, my only option would be to use a custom field type. This makes me sad =(. It also means that it's unlikely that such a custom viewreference widget module would ever reach contrib land.

The point

So! My suggestion is to add a new third column to the field schema - 'other_settings' - with the expectation that any old module can bung stuff in there, within the field value, and it will stick around. Then it would be possible for multiple contrib modules to come along and consistently extend the viewreference widgets with arbitrary custom config.

Patch to follow.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jamsilver’s picture

A further note. It would seem that one of the core design 'features' of Drupal 7's field system is that field type modules are explicitly incapable of smoothly upgrading their field schema. See:

#937442: Field type modules cannot maintain their field schema (field type schema change C(R)UD is needed)

So, I suggest that there are two approaches we could take to add this feature:

1. Add a totally *new* field type (e.g. viewreference2) with the extra db column. We 'deprecate' the original field type, perhaps hide it from the UI, and encourage users to use the new type for new fields. Still allow/support the old one to work for existing fields. But modules hoping to use the column will only work for viewreference2 fields. This is the approach taken by the Media module for its old "Multimedia asset (deprecated)" field type.

2. Write an update hook which performs the db schema update anyway, hardcoded to only work with the standard sql field storage backend. This will work for 99.99% of users. This is the approach taken by the Entity reference module. See entityreference_update_7002(). It sounds hacky, but actually probably works very well because most people who are not using the standard sql backend (or equivalent) are using Mongo and that ignores field schema anyway (since it doesn't need it) so will work just fine.

I personally prefer option 2, but will aim to submit a patch for each and leave the decision to module maintainers and/or general discussion on this ticket.

jamsilver’s picture

Approach 1: New field type patch attached.

To clarify, this is *not* my favoured solution. Watch this space for a patch for approach 2.

jamsilver’s picture

Assigned: jamsilver » Unassigned
Status: Needs work » Needs review
FileSize
5.56 KB

Approach 2: Update field schema patch attached.

This is my personal fave. Simply because it will in all likelihood work for everyone except those that are using highly custom, non-sql-compatible backends which still care about field schemas (i.e. not Mongo or similar). And those people (if they exist at all) will be specialist and will be expecting issues like this and will be prepared to fix it customly for their custom backend.

And it means we aren't stuck with legacy field types clogging up the code, the UI and future development effort going forward.

danielb’s picture

Status: Needs review » Closed (won't fix)

That's completely unreasonable.