Support FIELDS as views rows style

subscribe

Subscribing...

I get the logic of why this is set up as it is currently, but really like msumme's suggested change:

There needs to be a way to select fields for the main view, and then from those fields select which will be in the thumbnails.

For my use case, only a dedicated content type -- call it promo_slide -- is would be pulled into the views slldeshow, and used to spotlight and link to other content, both on that site and elsewhere. That's easy to do with fields in views (the content type has a title, image field and "destination URL" field, which is then set as the link source for both the title and image). But on a teaser or full-node view, there's no easy way to have it link to anything but the node itself.

I can work around this by custom-theming the teaser for our custom content-type, since it'll never need to display outside the slideshow. But that's probably not the case for most uses, and it would be great to have Views' super-granular field control for the main "hover" display, as you do when using the single-frame option.

It doesn't look like it would be too difficult to override a function or two and have the thumbnail-hover view use the exact same field settings for the main hover display and the thumbnails -- which, with some creative CSS, could probably address most needs. But I still think msumme's idea of "pick your main fields, then pick the one(s) used in thumbnails," is a better approach, if it's possible/practical.

I've been thinking about this, and think it's doable.

In the style options, there could be a radio selector in the Thumbnail Hover dropdown:

Main frame:
0 Node
0 Fields

Then when Fields is selected, a list of all fields used in the view:

Display the following fields in the Main frame:
X Node Title
_ Image (with a teaser imagecache, used for smaller frames)
X Image (with a larger imagecache, set to not display in the default view)
_ User name
_ Post date

It'll take some work, on digging out the proper field options, on adding imagecache options to image fields (which is another alternative to the display/not display for the common use-case of different sized images), and on adding the jQuery to make it fancy.

We should definitely add this to the roadmap to full release of v2.

In the meantime - how could we exclude the node body field being loaded in the main div? Is there an easy solution?

Great module otherwise, thanks for the effort!

Don't add it as one of the fields. Or am I somehow confused.

The problem is that thumbnail hover ONLY supports splitting up the thumbnails and main section by using the teaser and full node. My thoughts on implementing this were very similar to aaron's idea:

* The thumbnail hover options should check the $view object to determine if the row style is field or nodes.
* If nodes, the options stay much as they are.
* If fields, there's 2 multiselects or checkbox lists that allow you to select which fields go in the teaser and main sections.

This approach lets us leverage built in CCK/views theming and formatters for fields which is nice. Bonus points would be sorting the fields independently of the normal views field order. This is debatable tho, as you could add the same field multiple times if necessary to get it to appear in a different order.

#8, redndahead:

Sorry, I wasn't too clear.

What I meant, was that if I use thumbnail hover mode and hover over a thumbnail,
the node teaser (or the full node) is displayed into main div.

I can then control which CCK fields of that node are displayed through here:
admin/content/node-type/[mycontenttype]/display.

I can exclude (or hide) all the fields (title, subtitle, etc.), but there's no option to exclude the node body (the main text of the node, $node->content['body']['#value'] ).

I would love to see this feature.

Here is the possible loop for enumerating the selected fields. Posting for future reference.

  foreach ($this->display->handler->get_handlers('field') as $field => $handler) {
    $options[$field]  = $handler->ui_name();
  }
      
  $form['fields'] = array(
    '#type' => 'checkboxes',
    '#title' => 'Fields',
    '#options' => $options,
  );

Edit: Added better code example

Thank you very much for this new revamped version

I have added fields support, allowing to show any content/teaser using cck formatters in views.
This way is possible to show images formatted with imagecache or custom links or body summaries using all the views power.

For this I have considered to use the existing Row Style configuration in views for the main content. This allows to select from full node, teaser node or fields when showing the main content.
And for the breakout teaser I have added the option in the views slideshow thumbnailhover configuration to select from teaser/full node or the same views fields from main content.

I have removed in the process some non-existing themes or js. ( I found that the views_slideshow.css in views_slideshow main directory is also unnecessary, but it is not removed with this patch)

Updated with last Oct-5 dev version.
removed code from tpl.php fixed in last dev revisions.

Probably there are question regarding to some of the changes done to support cck fields,
I know there are many different ways to approach this and set defauit values.
To test this patch I could provide a full directory as another contrib views to evaluate better.

Here's my approach to this issue. If the view's row style is set to node, it will display as it always has. If the style is set to fields, instead of the "Hover breakout" setting asking for teaser or node, there are two sets of checkboxes asking which fields you'd like to use for the main slide and the breakout teasers. This lets you add and order fields and leverage those formatters.

Same patch minus formatting issues

+1 on this feature

Results of testing patch #17 on 6.x-2.x-dev (2009-Nov-06):
On the slideshow style settings I get this error:
warning: Invalid argument supplied for foreach() in /home/manuel/htdocs/drupal6/includes/form.inc on line 1205.

The options do change depending on whether you are using fields or node Row style, and the options available for the fields row style look ok. You can change the settings and they save fine.

However it doesn't affect the output of the view when looking at it, still does the same as if it was not patched.

I have the same issue. Mine doesn't show any of the thumbnails.

This one is a reroll from dev plus it fixes the menu errors. I made a mistake on my last post. It works fine now. Pretty cool.

@manuel Can you check again and verify that it's still broken using the latest dev with this patch?

Great redndahead, patch applies fine, it works, and no errors come up.

I'm setting the status to needs work, because it renders everything as is, no divs or anything surrounding each field, which makes it very hard to style with css, if you are listing several fields.

I think it should use a similar technique as what normal unformatted style uses.

Manuel. You can still use views templates to style the fields. It works the same way as usual views fields does.

I think I actually agree with Manuel Garcia -- I don't like that it doesn't use views tpl files to format the output. This lead me to think we need to do some work on how slideshow outputs. There's a great deal of waste because the $rows are rendered, and all the theme() calls in the tpl.php are bad. I think we should consider moving all this logic to preprocess functions.

However I also think this patch should get committed because it's much better than the current implementation and you don't lose any functionality. Haven't reviewed the actual patch yet -- will do so soon (I hope!)

I said you CAN use views templates to style the output. There is nothing keeping you from using .tpl.php files to change the field output. Am I missing something?

I do agree that I don't like the theme() calls in the tpl.php files. We have to somehow balance what we don't like with what year we would like to have a release. I already have about 50 ideas for a 3.x release and I'm trying to hold the unnecessary one's back or we won't get done.

If you look at theme information in the views settings, it will outline the .tpl.php files that are applicable for the individual fields, however those files aren't honored. This is because this patch only renders the fields in order to get their output. In other (views core) implementations of fields, this is simply supplied as the preprocessed $content that is available to the *field*.tpl.php file when using other styles (i.e. unformatted, list, etc). This implementation ignores that, and I think that's a bug.

That said the patch applies, the slides and "teasers" both get rendered correctly and I can't reproduce the issue Manuel raised with this patch, so RTBC. I'll work on the preprocessing in a separate issue

I'll commit. But I used views-view-field--slideshow-thumbnailhover--page-1--title.tpl.php to theme the title field and it worked as expected. I'll be interested to see what you come up with. May want to take a look at this issue. #613042: Convert theme() functions into views-themeable tpl.php's

commited This is one awesome feature!

Ah yes, my mistake, fields works. The ROW style doesn't, which is why the containing divs that are in the core views implementation aren't there. I was just looking at the issue you referenced, and it lines right up with what I was describing for the breakout section.

I'm glad the feature is in, thanks a ton guys =)

About the issue of the fields' output not having markup, I took a look at the module's code, but I got very confused on how things are getting done.
Not sure what's going on, and the tpl file makes no sense to me, they are supposed to be for markup and echoing variables, not switching theme functions.
I aggree we should rethink the architecture on outputing results, but the module is very new to me so I guess i'll stick to testing out what you guys come up with =)

The final committed version is really better in terms of configuration compared with my proposal, but it introduces the nasty issue with fields theming.
I have seen that the views-view-field-xxx class only works when theming full nodes but there is no implementation of theming the same for fields on itself.

While we create a new theme/template that mimics the node field theming I have created this patch that makes the field styling compatible with old versions,
(even with my fields patch that worked as it was displaying all the node) and it helps clearly in theming the output of the views slideshow.

I consider this patch a workaround as last commited patch was releases with a known issue, even though, and I agree with fearlsgroove, this version is much better than previous one.
It could help to have nice views slideshows while we have a nice template theming.

Patch applies fine against latest dev, and does what it should, thanks!

I think there's one more thing to do though, and that is to only provide this:

$rendered_fields .= '<div class="views-field-'. views_css_safe($view->field[$field]->field) .'">';
$rendered_fields .=  $view->field[$field]->advanced_render($node);
$rendered_fields .= '</div>';

if the results are not blank, so we dont end up with empty divs geting printed out.

Other than that, with this patch we can now at least target everything in our css =)

Good suggestion,
what about this?
it is the same but it just render fields if they are not empty.

Looks good to me jcmarco, patch applies fine and does as advertised =)

Perhaps a code review would be nice from the maintainer just in case, but as far as needed theming markup/classes it does the trick =)

This has been committed. Thanks guys! If you have any other issues please open them up in a new issue.

Thank you