Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Right now it's very difficult to create any sort of hierarchical view, meaning galleries, forums, etc
We can allready group by one field but we should be able to group by multiple field.
eg.
Monday
-Morning Session (9-noon)
--Event, room
--Event, room
--Event, room
-Afternoon Session (1-4)
--Event, room
--Event, room
--Event, room
would be:
Group by Day
Group by Session
Sort by Day, Session, Event
Comment | File | Size | Author |
---|---|---|---|
#56 | cck-grouping_fix_records_foreach-477338-56.patch | 1.14 KB | alexh58 |
#48 | group-on-multiple-fields-477338-48.patch | 12.39 KB | fabsor |
#47 | group-on-multiple-fields-477338-47.patch | 12.44 KB | fabsor |
#40 | multiple-grouping.patch | 20.58 KB | casey |
#35 | views-multiple-groupings.patch | 20.11 KB | casey |
Comments
Comment #1
dawehnerI'm wondering whether http://drupal.org/project/views_tree would be enough?
Could you try out this module?
Comment #2
YK85 CreditAttribution: YK85 commentedsubscribing
Comment #3
MBroberg CreditAttribution: MBroberg commentedI have been looking at Views Tree but cannot get it working.
It seems like you have to have a pointer to some sort of parent field.
What I want is to be able to select a bunch of fields for display, then group them in any fashion that makes sens to me at the time.
For example in one view I might have:
Monday
-Room 1
--Event, time
--Event, time
-Room 2
--Event, time
--Event, time
Tuesday...
while in another display I might want:
Monday
-Morning Session (9-noon)
--Event, room
--Event, room
--Event, room
-Afternoon Session (1-4)
--Event, room
--Event, room
--Event, room
and in another view I might want:
Instructor 1
-Monday
--Event, location, time, room
--Event, location, time, room
--Event, location, time, room
Tuesday
--Event, location, time, room
--Event, location, time, room
So I need unlimited nesting levels with the ability to choose a "group by" for each level from any field that is currently in the field list.
It should ideally be very similar to the current "Group By" function, only allowing more grouping levels. Perhaps the "group by this field" should be a setting for the field, or put grouping in an area similar to "Sort Criteria" so that you could drag and drop the grouping levels in a similar manner to sorting levels.
Comment #4
simeI would do this by ordering nodes by event date and adding grouping for some of the fields:
eg.
Monday
-Morning Session (9-noon)
--Event, room
--Event, room
--Event, room
-Afternoon Session (1-4)
--Event, room
--Event, room
--Event, room
would be:
Group by Day
Group by Session
Sort by Day, Session, Event
Comment #5
MBroberg CreditAttribution: MBroberg commentedYes that is what I want too but how do you do "group by" field 1 and then "group by" field 2?
There is only one "group by" in the display settings.
Comment #6
simeIt's not simple to have two grouping fields (as far as I know). The best way I can recommend is:
1. The first two Fields are your grouping fields. But remove their labels and set them to "Exclude from display"
2. Your third Field choose the group "Global" and add "Global: custom text". With this field you set the Text to the combined output of the first to Fields.:
3. Go into your display settings and select this third field as the group-by field.
4. Add whatever other fields there are.
Another approach is to have a view as the display for each major node type. So on full/teaser view of the "Instructor" node type, you display a view that shows day/event information. Obviously creating the views is pretty easy and you'd have to work out the best way to add these to the node view (which is outside the scope of the views issue queue).
Comment #7
MBroberg CreditAttribution: MBroberg commentedThank you, I have been using both suggestions as a work-around but neither gives me true nested grouping, so it is still a "feature request" if it ever becomes possible.
Method # 1 gives me a single "group by" field with multiple fields in it, which is OK as a temporary solution but still repeats data in each header and does not allow indenting.
So I get:
Monday Morning
-event
-event
-event
Monday Afternoon
-event
-event
-event
and what I really want is
Monday
-Morning
--event
--event
--event
-Afternoon
--event
--event
--event
Thanks anyway for your suggestions.
Comment #8
dawehnerI wrote a basic patch which allows to group by more then one field, but it's not ready yet
Comment #9
dawehnerSo here is a initial not full working version
Comment #10
twistedindustries CreditAttribution: twistedindustries commentedDoesn't work for me, or at least not the way I had expected. When I apply two grouping fields it always ignores one. I am trying to accomplish this with two date fields.
Comment #11
tomdisher CreditAttribution: tomdisher commentedSubscribing.
Comment #12
alex.skrypnykSubscribing
Comment #13
anivad CreditAttribution: anivad commented+1 subscribe
Comment #14
merlinofchaos CreditAttribution: merlinofchaos commentedThe approach seems okay. In an ideal UI, maybe what we would have is where the user enters a number and clicks update and then it comes back with the right number of fieldsets.
The @todo definitely needs to be completed for that to work, since that means an arbitrary number of recursions in order to group properly.
Comment #15
Fannon CreditAttribution: Fannon commented+1
Would love to see this in Views!
Comment #16
zeezhao CreditAttribution: zeezhao commented+1
Comment #17
topmet CreditAttribution: topmet commented+1
Comment #18
Shadlington CreditAttribution: Shadlington commentedSubbing
Comment #19
arx-e CreditAttribution: arx-e commentedSubscribing
Comment #20
dawehnerHere a question from mail, because the user didn't posted in the issue queue but i think that's interesting for everyone.
I don't know anymore what worked on the patch, but i guess it's more
an api level change at the moment. From reading the patch i would guess the Idea exist, but not sure how far it is.
One part which definitive have to be done is a actualy way to alter the behaviour via a template. There should be template for render multiple views.
If you want to complain about my ignorance, think that this patch is nearly one year old....
If there would be more recent work, i would have posted it here. There are probably some other issues which i worked on in the meantime instead. In general there are always a lot people involved when it comes to views wishes/bugs/features/tasks etc.
Comment #21
gagarine CreditAttribution: gagarine commented- double post -
Comment #22
gagarine CreditAttribution: gagarine commentedI adapted the patch to be able to use it in template.php via theme_views_view_list.
also on https://gist.github.com/1172621
#673982: Group by several fields at the same time was closed as a duplicate.
Comment #23
jdufaur CreditAttribution: jdufaur commentedSubscribing
Comment #24
AlternateRoute CreditAttribution: AlternateRoute commentedSubscribing
Comment #25
FreeFox CreditAttribution: FreeFox commentedHi all,
I hope this is the right issue to add this because there are about a dozen of issues about "GROUP BY".
After reading all the issues and other posts about "GROUP BY", including about 8 hours of testing the "Use Aggregation" I want to propose my idea of adding 1 option to the "Sort criteria" dialog. Now you have "O Sort asc" and "O Sort desc" ... What about a 3rd option => "O Group by". (see a visualization in attached image).
This would make grouping by 1 field very easy and I guess it would help many users.
Hope this gets a chance ^^
Thanks in advance
Freefox
Comment #26
gagarine CreditAttribution: gagarine commented@Freefox group by on one field is not a problem and is an existing feature, this issue is about grouping by more than one field...
Comment #27
FreeFox CreditAttribution: FreeFox commented@gagarine: if you put multiple field in the sort criteria you could group by multiple fields
Except for the table view where you can group, how can I group by 1 field? More in detail, I need it in the JSON export format.
Comment #28
gagarine CreditAttribution: gagarine commented@FreeFox
Nop you can't group (like in a list). I updated the issue description to make it clearer.
please google it or open a new issue.
Comment #29
patoshi CreditAttribution: patoshi commentedi'm also running into this same issue. From my research so far, it seems the only to do this effectively is to create nested views by using this module: http://drupal.org/project/views_field_view
In effect you would get an output like this: http://prntscr.com/4fvu2
This seems a bit cumbersome if you nest 3+ views together. How can this be resolved with a single view?
Also another problem I noticed with the default group by settings in views 3.x is that the "group by" field is repeated on every result and I dont see any way of disabling it besides creating a tpl or hide it with css.
Comment #30
gagarine CreditAttribution: gagarine commented@duckx what about the "solution" I explain in #22?
Comment #31
casey CreditAttribution: casey commentedUsed patch of dereine in #9 as a base.
I think it is fully backward compatible. This patch allows you to use a unlimited number of groupings.
Configuration form could use some ajax (now you need to save and reopen the style options form for an extra grouping field).
Comment #32
casey CreditAttribution: casey commentedMinor improvement
Comment #33
dawehnerNice! Thanks for working on this feature, really like it already sadly there are some parts.
Did you runned the simpletest for the groupby?
Why does the $form have to be unset here? Isn't the form not rendered yet?
Could both parts use the [0]['field'] syntax? This shows a bit better what's done here.
What's the reason to add $c = ... if $c is not used somewhere else? This syntax might be known by less developers. If the $c is needed move it one row up ...
I like it that the parts are seperated better then before
The indentation looks a bit odd here.
here as well
I'm not really sure whether we should change the arguments of this function at that point ... You know people might rely on that in their style plugins. Let's discuss about that as every change creates a shitstorm
Oh i didn't saw that, this looks fine! Forgot my last comment :)
I'm wondering whether it would make sense to add another template here as views theming is done nearly all the times with templates.
Btw. why is $view needed here?
Comment #34
dawehnerThe test is "Views plugins -> Styles"
Comment #35
casey CreditAttribution: casey commented- Altered code according your comments.
- Fixed styles test.
- Renamed ViewsPluginStyleTestCase::testGroupBy to ViewsPluginStyleTestCase::testGroupingLegacy
- Added a new test ViewsPluginStyleTestCase::testGrouping testing multiple groupings.
Comment #36
Reg CreditAttribution: Reg commentedI just came across a simpler form of the same problem and was referred here. I came up with a possible solution and thought I would link over to it just in case someone else can benefit from it (not sure if it will be a good solution yet but but it might help someone). Here's the issue: http://drupal.org/node/1383696#comment-5400920 .
Comment #37
Reg CreditAttribution: Reg commentedFYI: I tried this workaround and it worked well for me: http://drupal.org/node/1383696#comment-5401116 . You could theoretically have as many subgroups as desired (only needed one) and you can theme it properly because there is now HTML distinction between the levels.
Comment #38
casey CreditAttribution: casey commented@Reg, sure that's another solution, but way more inefficient.
Comment #39
Reg CreditAttribution: Reg commented@casey Agreed it is probably less efficient, how much so I have not tested but it certainly creates more HTML (there are modules to cut down the HTML views creates) than I would like and probably more queries. On the other hand how much are your displaying? If you are pulling up 3 records from the outer group it's probably insignificant in extra overhead.
However, it does allow you to solve a problem without a patch and right now there is no in-built working methodology so having alternatives to choose from is certainly a good thing.
Comment #40
casey CreditAttribution: casey commentedChanged test to use two different fields for grouping
Comment #41
dawehnerThanks!
Made another final review and decided to commit it, maybe it's worth to backport it.
For follow ups please open new issues.
Comment #42
casey CreditAttribution: casey commentedLooks like you forgot the new views-view-grouping.tpl.php
Comment #43
dawehnerOH yes, thanks!
Comment #44
philsward CreditAttribution: philsward commentedWhile I haven't tried out the patches, this appears to be along the lines of some issues I ran into and started thinking "Fields should be organized by groups". Thinking about it and doing some research in the issue queue, I've realized that "Groups" is a term that is overused with Views and should be left to the existing uses. I think a better term would be "Clusters".
What I imagine, is by default, there is one cluster of fields (which is how views works now) but you could add in a second cluster with specific fields and maybe even a third cluster. Each cluster would be independent of each other but the output would all be on the same page.
Example:
Field Cluster 1
- Node: Title
- Node: Teaser
Field Cluster 2
- Node: Title
- Node: User
Now, what I also envision, is that these clusters, being independent of each other, could be stylized independently of each other. For example Cluster 1 could be displayed as a table and Cluster 2 could be a grid. Also, these clusters could be included into the arguments so that if cluster 1 doesn't validate, then show cluster 2 instead. Each cluster should also be allowed to be filtered and sorted independent of each other.
This type of setup would allow for much greater display of data within a page. Especially when utilizing arguments. As it is, if an argument doesn't validate, the current options are very limited on how to display the data.
---
The only other way I can think of to accomplish this type of setup, would be to join two view displays together, something I don't think is possible right now but I also personally think this would create more overhead on the view. I've thought something like this could be accomplished also by using panels, but that also seems like a lot more work and system overhead than really necessary.
---
Another use case scenario that got me thinking about the need for this, was trying to use "Views Slideshow" to accomplish a "tabbed ajax display". In my dealings, I realized that this isn't possible because there was no way to separate the fields for views slideshow to independently scroll through three different cck fields on the same node. (Each field is a text field with unlimited addons) I basically have "Specifications, Features & Options" cck fields and I wanted to use the views slideshow pager to scroll through each field for that node. It's easy with arguments to only show the fields for the respective node, but the way views is designed now, it's either all of the fields show up or nothing. The existing format lumps all of the fields into one single cluster.
---
I'm sharing my thoughts in hopes that it will help open the doors to some of the possibilities of what I believe this issue is modestly trying to accomplish. Some might say "just throw some PHP code at it to get it to do what you want". I am speaking for the group of people who can't code. The one's who use Drupal out of the box and if it doesn't do it out of the box, we find another way of doing it or don't mess with it at all.
Thoughts?
Comment #45
trofimchouk CreditAttribution: trofimchouk commentedHello! Is there any patch for 6.x-3.x version?
Comment #46
patoshi CreditAttribution: patoshi commentedso i came up with something else using the global php field. please let me know if this way is inefficient or not compared to the patch you guys have:
i tried other methods but this seems to be the best method as it seems. the problem from wat i remember was that you had to keep track of the previous views-row data to see if it matches the current month/day its processing.
i got it working like this:
http://prntscr.com/5qexn
views page: http://prntscr.com/5qeyj
my global PHP field: http://prntscr.com/5qf0a (you will need to re-purpose this for your own use.)
page styles settings: http://prntscr.com/5qf34
please do tell, if you find a better solution without the custom php.
As requested by lancelot:
Comment #47
fabsor CreditAttribution: fabsor commentedHere is a first try at getting this to work in Drupal 6. A few notes:
* There were no tests for styles at all in 6.x so I skipped this in this version.
* I do a render in the theme function, since the preprocess is not called. We might want to do that in some other way.
Comment #48
fabsor CreditAttribution: fabsor commentedOops, that patch failed on everything but grouped views. Here is a better one =)
Comment #49
mikolaskova CreditAttribution: mikolaskova commentedHi fabsor,
I installed the dev-Version for applying your patch, but now I don't see how to make use of it.
Grouping is activated, the fields are set to "group results together" but nothing happens.
I found the grouping settings in the table-settings (which I used before), with your patch there are more options now, but when I use two grouping options, everything disapears.
(Its a view about school events, I want to group them by month and day, so that all events on the same date are grouped by this date, all events of the same month are grouped together)
Thank you
regards
Adriana
Comment #50
giorgio79 CreditAttribution: giorgio79 commented#41 I don't see any commits for this issue for 7x at http://drupal.org/node/38878/commits?
Comment #51
dawehner#50
This is a really old commit: aa67578160d87ae994748abcd52a5035dcc57ccb
Comment #52
giorgio79 CreditAttribution: giorgio79 commentedThanks, much appreciated.
Comment #53
dawehnerTo be honest I don't think that now nearly one year later someone cares that much about Drupal 6 that it's worth to add the feature in there. It would require additional testing etc. so it seems to be better a won't fix for 6.x-3.x.
Comment #54
philsward CreditAttribution: philsward commented@dawehner I guessing because of views attachments and the use of other workarounds like panels kind of makes this issue somewhat obsolete...? Just my guess...
Comment #55
dawehnerI'm not sure how to use panels/views attachments to achieve this behavior, well maybe it's possible with views_field_view :)
Comment #56
alexh58 CreditAttribution: alexh58 commentedJust an FYI to anyone who chooses to use the patch in #48:
It breaks CCK 2.9 nodereference select fields (that use the views module, as the selector).
I believe this is because of how the results variable is setup and that it gets split into groupings and rows. Anywho—for those who are using this wonder grouping patch and want their nodereference select fields to remain working, I'm attaching a patch that just changes a one line in the nodereference module and that respects this new format.
Comment #56.0
alexh58 CreditAttribution: alexh58 commentedUpdated issue summary.
Comment #57
MustangGB CreditAttribution: MustangGB commented