Patch: Allow wrapping groups of fields in tags (prefix and suffix per field)

I have used this patch successfully on several projects now. Views itself, and Drupal core commonly use #prefix and #suffix for container/wrapper divs, so as far as the end result, I think it is on track.

The UI is a bit funky, but I still drastically prefer a more confusing UI at this level than having to create and maintain a separate template file (which isn't theme agnostic).

Here's the same patch, but rolled with --no-prefix and --relative so it applies cleanly when using drush_make.

What it do

This patch generate a configurable fields wrapping functionality for fields in each rows.

How to use

Into attachment you can see fields interface where you can configure your wrapper for fields.

Fields without wrapper don't change, other are wrapped from "Wrapper" element with "Wrapper class". If more then one element have the same "Wrapper" and "Wrapper class" this fields are aggregate from then same wrapper.

Configuration into screenshot generate this output:

<ul class="test">
  <li class="views-field-tid"><!-- FIELD --></li>
  <li class="views-field-image-path"><!-- FIELD --></li>
  <li class="views-field-created"><!-- FIELD --></li>
</ul>
<span class="views-field-title"><!-- FIELD --></span>
<div class="views-field-occhiello"><!-- FIELD --></div>
<div class="another-test">
  <div class="views-field-comment-count"><!-- FIELD --></div>
  <div class="views-field-view-node"><!-- FIELD --></div>
</div>

Let me know if you found some bug or require some improvement.

Fixed wrong order for element without wrapper and wrapper element.

I've applied the patch, but it's only printing the wrapper without the wrapper class. I'm using Semantic Views 6.x-1.1 and a Zen 2.0 subtheme. Anyone else experience this?

@wingzinco: can you send me (use pastebin :P ) a demo views with this error? Thanks!

@mavimo - Sure, here it is: http://drupal.pastebin.com/eMsLShfD

I have a class set on each wrapper element, but it doesn't seem to be printed in the view.

Thanks.

Any further thoughts on this? I'm using jQuery to wrap a div around a group of content, but there is the delay of waiting for the DOM to load before my styles are applied. If this could be solved with this patch, it would be a huge benefit. Thanks again for anyone willing to help.

@wingzinco: this patch solve your problem (views generated page and block).

#10 & #12 fixed.

@adamdicarlo: I'm agre with you but using tag-class combination is the simple and powerfull solution I found. I also think to create a wrapper elements are fields and configure it, but is more complex and not really fast (it don't work on theming layer but in query layer with a lot of possible problem on performance).

Hey there,

this is a nice patch, but I have to say it's very limited.. it would be nice if someone were able to create something more generic, where you could really create multiple level wrappers for any fields, so you might want to have an image left and a content area right, and then several sections inside that content area etc..

But anyway, kudos for this and just as a note - this is something I could use on basically any site, so it's a really great thing to have.

Cheers,
Martin

@arski: I'm agree with you, but add sub-wrapper can increase UI complexity, and I don't know how to "manage" this functionality (UI side), but if you propose a mockup i can try to implement code to make it possible :)

Sub-wrapper also reduce "the Semantic" of element, but this is just a "sub-issue" :P

you're right, it's not easy UI wise. Off the top of my head I would create something similar to how Fieldsets work in CCK. So basically have a new field type like "Field group" and then when you go into the interface where you can move view fields up and down, have the option of moving them inside a field group as well..

To be honest I don't think this can be done in the semantic views interface, but it should be doable in the default views interface in the fields section.. or?

@arski: is not possible add this functionality into Semantic Views, SV interact into theming functionality of views, field is data-related and is not "correct" insert theming functionality into it, but is also possible create a similar interface into SV settings, I'm try to "immaaginate" this interface and how to set that on options.. not simple, but not impossible :)

The balance I'm trying to strike with Semantic Views is to fulfill all of the possibilities of the Views field row style (which offers interchangeable HTML elements, but only span and div) and add crucial functionality to simplify theming where it costs very little to do so.

Ok, implement the simple but powerful feature - editing the row/view templates from the UI.

P.S. I had the same task (wrapping of semantic-views fields), but I've used Global Custom fields with HTML-markup parts. There are no problems with that solution.

I haven't reviewed this patch, but regularly use Semantic Views and have run into the same need. My quick-and-dirty solution is to exclude and rewrite the fields, adding tags as needed.

For example:
*****************************
Field-1: exclude from display
Field-2: exclude from display
Field-3: exclude from display

Field-4: rewrite output to include fields 1-4 (you can use HTML here if needed), then give Field-4 the div element using Semantic Views to wrap them all inside.
*****************************

This probably isn't the best solution, but I thought I'd post in case it helps someone who needs to wrap fields while the patch is being evaluated.

There seem to be two proposed approaches here. Perhaps Bagpound could comment on whether either of these is likely to be included in Semantic Views. This would give early adopters using a patch a view on which one would minimise the need for rework later.

Being able to group some fields in a wrapper is something I need. Whilst the global custom fields approach works, it seems messy since it makes view changing more difficult and creates another place where CSS is kept. Something built into Semantic Views would be really good. In principal either of these could functionally do the job.

subscribe

Has there been any more thoughts on this? Has anyone explored if there's support for this in Views 3 since it has elements of Semantic Views incorporated?

@monotaga: I'm working on a solution for having wrapped fields with D7 and V3, update into next weeks.

You could use Views along with Display Suite. Display Suite allows you to add custom fieldgroups that can be displayed as a div element with whatever classes you would like to apply.

Could you also provide this for the D7 version? I would love it!

I was looking for a way to do this and ran across this issue. When I saw there was no D7 version, I started playing around with another solution. It seems, at least with D7, that you don't need extra modules or patches to do this.

My need was to put a product image on the left side and then list product details on the right. What I ended up doing was to create 3 global text fields. The fields are laid out as follows:

1) First a global text field with its contents set to: <div class="product"><div class="product-image">

2) Then I display my image as normal.

3) Then another global text field with contents of: </div><div class="product-details">

4) Then I list all my detail fields.

5) Finally a third global text field containing: </div></div>

The key is to make sure Customize field HTML, Customize label HTML and Customize field and label wrapper HTML are checked under STYLE SETTINGS in each global text field. All three of these should have a value of -None- in the element selector. All Create a CSS class and the Add default classes should be unchecked.

Fantastic thanks for that... great tip! I'll be using that a lot for sure.

I use panels and a custom panel to achive this. Or and is comment #23 is a way to also solve it.

Moving to 8.x-2.x and keeping it active to see if this is needed in never version.

cameronbprince, your solution (#31) is brilliant!

I noticed that Semantic Views is incompatible with Views fieldsets.

Should I open a feature request about this incompatibility? Or is it by design impossible and should be solved like the patch in this thread?