There are cases when you know you want to embed the same view with the same args pattern in all the nodes, and you don't want to have node authors wonder which view they should select on the node creation form.
example : 'this node is referenced by' (with nodereference field).

In order to do this, you currently (before viewfield arrived :-) ) have to set your view as a block, put the right argument building code, configure your block's visibility with the right php snippet... and you have the result in a separate block, at best below the Maybe a "computed field" could also do the trick, but it's still... complicated.

For these cases, it would be handy to have the possibility to specify a view and an arg pattern directly in the viewfield settings. If these values are set, the viewfield is "locked" and does not output anything in the node edit / creation form.

As a matter of fact, I see many use cases for the viewfield module, and most of them belong to this 'same view / same args' scheme...

CommentFileSizeAuthor
#7 view_field_0.patch6.23 KBeaton

Comments

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

An easy way to do this and keep the existing functionality might be to throw in some logic to the effect of:

"If there's only one View possible to select here, then don't show the select box on the node add/edit form. Else, display it."

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

Oops. That comment makes no sense; I was basing it off a preliminary 5.x port that Eaton had done, but that feature has since been removed since it was causing problems. :)

mfredrickson’s picture

mfredrickson commented

This is a valuable feature indeed.

I think the best method to implement would be another widget called "Locked View". With this widget, the content type creator would choose the views/args/exposed filters at content creation time. Node authors wouldn't even know the data was there.

It could be easily implemented as '#type' => 'value' form in the widget.

One nice thing about this implementation is that you could have 1 view field, but use it with different widgets (allowing for selection or not at node creation time).

-M

yched’s picture

yched commented

This could be another widget indeed - or be additional settings in the field settings form (widget part), you'd still have the 'per field instance' behaviour.
Solution #2 adds a little clutter to the field settings form (not a big deal in a collapsed fieldset - see date.module's field settings !)
Solution #1 lets the user face a possibly cryptic widget choice (something like "constant (hidden in forms)" ?) There is more room for explanations in the field settings page.
So I guess #2 has my personal favor, but hey, that's your call :-)

mfredrickson’s picture

mfredrickson commented

@yched: Did I see something about default values automatically handled by CCK? Would this meet your need?

I've been thinking about a nodeapi system that uses CCK fields and widgets to apply settings across every node of a given content type (or better yet, every node in a view!) I think that would be (potentially) an even better, generic way to solve this issue.

yched’s picture

yched commented

default values automatically handled by CCK? Would this meet your need?
Probably sort of... :-).
The default values in cck "only" pre-fill node creation forms with suggested values set by the admin.

So maybe there's no need for an additional "locked" widget or additional cruft in the field settings form : a simple "non editable" checkbox could do the trick (probably with some validation : a "non editable" "required" field with no "default value" is problematic)

Of course, there is the possibility to leave that to a hook_form_alter in a custom helper module, but...

eaton’s picture

eaton commented
StatusFileSize
new view_field_0.patch6.23 KB

Here's a patch that offers three kinds of behavior:

1. Each node gets the view and args filled in separately (Current behavior)
2. Each node gets its own view and args, but it comes pre-populated with the default.
3. The defaults are effective for ALL nodes of this type, and no configuration options appear on the node edit page.

As an added bonus, it allows you to choose different view types as display formatters. List view for teasers, thumbnail grid for full node view, anyone?

eaton’s picture

eaton commented
Version: 4.7.x-1.x-dev » 5.x-1.0

Er... I just realized that my patch is against the 5.0 version. I haven't tested it under 4.7.

yched’s picture

yched commented

Eaton : how does your 'Provide a default view for each node' compares with cck's built in 'default values' ?
more generally, as I wrote in comment #6 above : combined with cck's default values, wouldn't a 'non-editable' checkbox be enough ?

mfredrickson’s picture

mfredrickson commented

First off, thanks for working on viewfield!

  1. I am going to wait to play with CCK's out of the box defaults before I include that part of the patch. I just also coded some default handling code into another field module, and this feature clearly needs to be at the CCK level, not a per-field thing. Let's put our effort into that.
  2. The plugin => formatter trick is pure gold.
  3. On the idea of type wide views: again, I think this should be abstracted out. I'd like to see "type fields" - perhaps denoted as a checkbox next to every field on the management screen - which allow for including the same data on every node of a given content type. I would prefer not to store N identical rows of data. Updating sounds like a nightmare. I'm not totally opposed to sticking that logic into viewfield, but I think it would help a lot of people if it were at the CCK level, not just in a single field module.

I'm going to put the formatter stuff in right away, and think about how best to accomplish "type fields" on a CCK level.

I've also been aching to come up with a better view selection form element, rather than the poor one I have right now. (Submitted as a patch to views so it can be used for other module, e.g. custom pager).

Finally, don't worry about 4.7 versions. This will probably only go into 5 anyway.

mfredrickson’s picture

mfredrickson commented

Plugins as formatters are implemented.

Thanks, Eaton!

eaton’s picture

eaton commented
Status: Active » Needs work

You're totally correct -- the default value handling should certainly be sufficient in terms of UI entry.

I still think that it would be very valuable to have a 'Lock to defaults' option for the module, though. Using the same technique that's used in this patch, we could simply check to see if the 'lock to defaults' flag is set on the field before trying to format it -- if it is, use the defaults. If not, use the saved value in the field instance. That would eliminate the need to update individual fields instances every time the main field is edited.

If you don't feel it would be worthwhile, that's cool, but I'm more than willing to reroll the patch in a cleaner fashion. It's a relatively small change (at least, done 'right' in the way you guys suggest) and it would really make certain use cases a lot simpler to build.

Any thoughts? Should I give it another stab?

mfredrickson’s picture

mfredrickson commented

How about another widget that wraps the $items array into a '#value' form element instead of actually outputting a form? For people with administer nodes, the form would show.

I too am happy to code this, as I already did it for another project:

http://cvs.drupal.org/viewcvs/drupal/contributions/modules/aclfield/aclf...

eaton’s picture

eaton commented

That would be perfect, using a different widget makes even more sense than mucking around adding another setting. Sweet idea!

moshe weitzman’s picture

moshe weitzman commented

"Lock to defaults" as described by Eaton is implemented in CCK Extras module - http://cvs.drupal.org/viewcvs/drupal/contributions/modules/cck_extras/RE...

wayland76’s picture

wayland76 commented
Status: Needs work » Fixed

With post #15, I'm happy to call this fixed

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.