Motivation
When you have some kind of numeric like filter, for example node: nid, field: field_name or some kind of date field
having just a pure textfield isn't enough.
At the moment people would have to write custom code to be able to do something like "4 or more" as a select option.
Proposed resolution
The solution to the problem is to provide the users to configure the options of the exposed filters.
With this patch you have an additional checkbox "grouped filters" which opens you a total new interface of allowed options.
Instead of a "single filter" you can configure each group item to use a certain operator and value.
You have several things in the userinterface you can do:
- Configure the operator of the group item, for example "between" or "greater"
- Configure the values of the group item
- Add a new group item
- Select the default group item
Fitler UI for a string filter
Filter UI for a number filter
Exposed Filter for the number filter
Remaining tasks
Tests from more users.
User interface changes
TODO
API changes
TODO
Original report by [dagmar]
I would like to implement a new kind a exposed filters into views.
I'm thinking in a combo box with like this:
Select Number Rooms:
1
2
3
4 or more
Of course this can be easily implemented into a custom module, and I know how code it.
However maybe this could be a more abstract feature in views 3, allowing filters to merge into a single form a combination of a filter and a operator.
User could define something like this in a UI
Operator Value Display
= 1 1
= 2 2
= 3 3
=> 4 4 or more
I understand that specially "Value" is a complex thing to define. But, maybe it is possible to implement without destroy all the filters handlers, what do you think? dereine? merlinofchaos?
I think exposed form plugins are not the better way to configure this, probably a redefinition of views_handler_filter can make this possible.
What do you think, is a very crazy idea, or not?
Comment | File | Size | Author |
---|---|---|---|
#160 | views-731662-160.patch | 82.34 KB | tim.plunkett |
#158 | views-731662-158.patch | 81.37 KB | tim.plunkett |
#155 | interdiff.txt | 488 bytes | tim.plunkett |
#155 | views-731662-155.patch | 81.75 KB | tim.plunkett |
#153 | views-731662-153.patch | 81.78 KB | tim.plunkett |
Comments
Comment #1
dagmarThe last line into the <code> tag is:
Comment #2
Manuel Garcia CreditAttribution: Manuel Garcia commentedI think its a great idea, though it sounds like quite a challenge to implement... just how you can build your query, build your exposed filter. Sounds definitely interesting!
Comment #3
dawehnerThis is definitive a very very cool feature. There are many people requestion this feature:
I would also like to see, for example: between 0 and 10, between 10 and 20, greater 20.
I think this will be hard to implement, definitive.
Comment #4
dagmarAn approach to achieve this task could be this:
In views_handler_filter add a new variable similar to "exposed", maybe "hybrid" is not the best word, but it doesn't matter now.
Alter views_plugin_query_default to call to hybrid_query() instead of query() for filters marked as hybrid.
In the filter UI provide a new button like exposed to generate hybrid filters, we could display something like a table with three columns.
Display | Operator | Value
Display can be a simple textfield, but operator and value have to be filled with the same forms that views displays in exposed forms. This allow us to insert a valid item for operator and value. As dereine said in #3 to get between 10 and 20, users should be able to select Between operator and fill the min and max value.
Ok, there is a lot more to consider, like the render form part, and well, a lot of other things, for now only ideas....
Comment #5
YK85 CreditAttribution: YK85 commented+1 subscribing - this sounds like a great new feature!
Comment #6
Bilmar CreditAttribution: Bilmar commentedsubscribing
Comment #7
dagmarOk, here are some screenshots of the ui. @dereine are we thinking in the same thing?
Comment #8
dawehnerThis looks fine! Does this form only appear when you click "expose in group"?
This will be awesome, damn, i have to present views3 again :)
Did you implemented anything already? I would like to help, as always :)
Comment #9
merlinofchaos CreditAttribution: merlinofchaos commentedThis is really interesting! I think the proposed UI seems workable.
Comment #10
webadpro CreditAttribution: webadpro commentedHi,
I'm just wondering if this has been released yet?
Comment #11
dagmar@webadpro: No it isn't have been released. It is a complex patch and I'm working on it in my free time. Please be patient.
Comment #12
dawehner@dagmar
I suggest we chat a bit about it. I also coded quite a bit on this patch.
Comment #13
webadpro CreditAttribution: webadpro commentedThanks for the quick reply. I can't wait to see it, because I'm actually in need of it for a projet for a client.
Comment #14
dawehnerThis will definitive be stable soon. You can still achive this with your own filter handler, which needs custom code.
Comment #15
webadpro CreditAttribution: webadpro commentedThat's great news; If there's anything I can help with let me know!
Comment #16
dawehnerI wanted to write that this will definitive not be stable soon :)
Comment #17
webadpro CreditAttribution: webadpro commentedI see alright. Well lets see what could I get done on my own.
Thanks
Comment #18
dagmarLets try to include this is views 3 soon. Tagging.
Comment #19
TC44 CreditAttribution: TC44 commentedthat looks great, this would be amazing to have.
Comment #20
dagmarLadies and Gentlemen, Start Your Engines :)
Here is the first version of this patch, I just tried it out using Node: Nid, as you can see in this video: http://vimeo.com/14533078
There are still a lot of things to fix, here is a list of TODO's:
I'm changing the status to 'needs review' to give a change to review things that are working at this moment. Enjoy :)
Comment #21
dawehnerJust for later
This should be less my default if add group works.
Comment #22
dawehneri called it can_expose_groups
This is possible now.
What do you mean with this?
Comment #23
dagmarFrom previous list:
Allow to add and remove items of the group using ajax (at this moment add group doesn't work, and remove item either).Provide a method like can_make_groups() (like can_expose()) to determine if a filter can create groups, if a filter doens't have operators, it cannot create groups.New items:
I mean use $_SESSION to storage the value of the group. We can postpone this part, is pretty complex.
Mmm, I'm comfortable with this way of working, like a ping pong of patches, there a lot of things to do, and code a bit each one will make this task easier. Other users of this thread are invited to participate too :)
Comment #24
TC44 CreditAttribution: TC44 commentedThis looks fantastic, thanks for all your hard work! I'll hopefully get a chance to test later this week.
Comment #25
Manuel Garcia CreditAttribution: Manuel Garcia commentedFirst of all, WOW.
Second, are you guys aware of this brand new project? http://drupal.org/project/views_dynamic_fields fork? should we hunt the author down?
[EDIT] OK, that module doesn't have much to do with this patch, [offtopic] still, perhaps they should provide a new patch for views3?[/offtopic]
Comment #26
dawehnerThanks for the explanation. So what have to be done is in filter::store_exposed_input
I'm wondering wether it would make sense to create a store_exposed_input_group and a store_exposed_input_basic
This would make it easier
This is already done by
No that's wrong i added the code which does this:
I tryed to add the reordering but it does not work yet. No idea why.
This looks better now.
I don't have a clue about this one. The problem is that in the submit handler both the form_state and the handler->options has still the removed item.
Comment #27
dawehner#25
I think in views3 this should be a exposed form plugin. I think there is none yet but it would be also possible as contrib module. The module is somehow a hack with hooks.
Comment #28
TC44 CreditAttribution: TC44 commentedHi, will #26 patch the Sept. 15 Dev version, or is it better to patch alpha 3?
I tried to patch and test with the latest dev, but was getting an error.
Thanks!
Comment #29
dawehnerAlways test again the latest dev.
Comment #30
dawehnerYeaaaaaah Tabledrag works now. At least when you add a new tab for the filter settings. *sigh*
I understand why items doesn't get removed
This is frustrating.
Comment #31
dawehnerWhat's missing
* Bug when you remove items. See above
* Allow to 'remember' the selection of a value
* Maybe, define a key for each item in the group. At this moment a numeric id is used, but probably this will be a complication when items are added or removed
That's basically it.
Comment #32
webadpro CreditAttribution: webadpro commentedHi,
Just curious, if I want to implement this custom code in my views module do I use the version of #30 OR #26?
Thanks
Comment #33
webadpro CreditAttribution: webadpro commentedI have just downloaded the lastest Dev copy and I get a hunk #2 succeeded at 3371 (offset 36 lines) when trying to apply either 30 or 26 patch.
Comment #34
dawehner#33
Okay this patch still appears, that's what we expect :)
Comment #35
webadpro CreditAttribution: webadpro commentedDo you know when will you have a new patch that will work with the latest Views Dev copy?
Comment #36
dagmar@webadpro "hunk #2 succeeded" means, I was successfully applied but the original file has been modified since the creation of the patch. (And the patch has been applied 36 lines below the original position)
Comment #37
webadpro CreditAttribution: webadpro commented@dagmar well thank you very much for the information. Its always good to know and I greatly appreciate it.
Comment #38
TC44 CreditAttribution: TC44 commentedI updated the latest dev and patched with #30, and was able to get it working!
Just want to give a big thanks, this for me is an enormously helpful breakthrough. I've been struggling with this issue for months trying to get something workable for exposed filters. It also worked on computed fields, which I was a bit concerned about. This seems to be the ticket.. thanks again!
Comment #39
dagmarRemember now works.
Related to "Bug when you remove items." I think this can go as is, I know, it is a problem of usability, but I think is not "so bad".
@dereine, $form_state contains the info to determine if there are group items to be removed, I tried to use this information to skip removed items, but it creates more problems that it fixes. Maybe you can found a better solution.
Mmm, I don't think this is a good idea, the current form is already complex to introduce another textfield to complete with and id. But If you code it, I will not complain :)
I didn't test this stuff using group by in a view, I'm afraid this will not work.
Comment #40
webadpro CreditAttribution: webadpro commentedHello I was wondering if I was the only one or not, but when I apply the patch (without any errors) the layout seems all weird. Please view the attachment and if anyone could help I would really appreciate it. Also i'm using garland for the layout.
Thanks.
Comment #41
webadpro CreditAttribution: webadpro commentedMy bad, this addon works great. I simply forgot to clear my cache. Thanks to all the developers!
Comment #42
dawehnerIs it just me that tabledrag doesn't work anymore?
Comment #43
dawehnerThis is now a working verison of the tabledrag.
Regarding the remove/add-bug. I think this is fixed now.
Comment #44
dawehnerWould be cool to get this in before alpha4/beta1.
Comment #45
bojanz CreditAttribution: bojanz commentedAttaching an updated patch, and an interdiff.
Mostly cosmetic changes (coding standard, english text).
Some explanations:
1.
When concatenation is present, then a ternary operator is avoided, so that we don't have to think about operator precedence and other ugly things. This is the drupal core way, I had a talk with people at #drupal-contribute (including merlinofchaos) about it a few months back.
2. In foreach() loops, $x is now $group_id. We don't really want a variable called $x, I have no idea what that means :)
3.
We need to take make sure the HTML tags open and close the right way, without intermixing with other elements. If we started our div before all other HTML, we need to close it after all HTML. If we started it after, we need to close it before all HTML.
Testing showed:
1.
2. Works for Node: Nid, but fails miserably for Node: Type.
When trying to use Node: type
a. Selecting "NULL" or "IS NOT NULL" as the operator doesn't hide the possible note types, the dependent code fails (this works with Node: Nid)
b. Submitting a hybrid Node:Type filter gives me:
This happens because $this->value now has an additional level, so I have $this->value[0] and inside it another array with all the node types (not just the ones I selected, which is also wrong).
So, the code counts the elements of $this->value, and fails.
3. During filter edit; removing an item from the group, or rearranging items, or adding new items has no effect, I save the form but everything stays the same. Changing the items themselves (item name or value) works.
Also, reordering doesn't just fail when editing, it fails when adding the group for the first time too.
Based on these three points, setting status to "needs work".
Additional notes:
I think that it's more in Views style to declare each one of these (title, operator, value, removed, weight) separately, instead of doing it inside the same array declaration. Doesn't matter much though.
Comment #46
j0e CreditAttribution: j0e commentedThis is a cool idea & I wish it worked but I'm getting the same problems as bojanz mentioned with regards to using it on a content filter for a cck field.
warning: mysqli_real_escape_string() expects parameter 2 to be string, array given in includes/database.mysqli.inc on line 323.
Also, I wish there were some solution that would enable a between ____ to ____ exposed filter for allowed values with two select lists. that's pretty standard for ui, so it may be already out there for views exposed filters for allowed values lists that enable multiples, but i have yet to chance upon it in any of the issues i've read. It is more intuitive than holding ctrl, shift for pc or command for mac.Comment #47
SuperXren CreditAttribution: SuperXren commentedHi guys.
Happy new year!.
Why after installed view 3 dev i can`t see "build group" button after clicked "expose" button ????
I saw http://vimeo.com/14533078 video - but it doesn`t help.
What`s wrong?
In attachment screenshort of my screen after clicked on "expose" button.
Thanks in advance.
Comment #48
dawehnerDid you applied the patch?
Comment #49
SuperXren CreditAttribution: SuperXren commentedWhy i should do this ?? i get the latest (today) dev version. Do i need to do this?
Comment #50
dawehnerYou need this for this feature
Comment #51
SuperXren CreditAttribution: SuperXren commentedguys, sorry for disturb, but when i apply patch (731662.patch) to 6.20 view i could not see combo box with my filters.
See attachment.
Thanks for help.
Comment #52
dawehner#51
Can you please export your view?
Comment #53
SuperXren CreditAttribution: SuperXren commentedYes, sure. Sorry for my stupid question, i`m new in patching drupal.
You can see export of the view attachment. If you have any question - fill free to ask.
Thanks.
Comment #54
Teezi CreditAttribution: Teezi commentedGlorious solution! Thanks a whole bunch to all the developers!
Comment #55
Teezi CreditAttribution: Teezi commentedIs there any means to prevent the filter being printed in the form submit button's div?
Comment #56
Pasko CreditAttribution: Pasko commentedHi, I'm quite new to Drupal. I tried to install the patch with both Netbeans and Eclipse, but it doesn't work for me, I can't see the group filter (Eclipse doesn't find a match with one of the files, Netbeans says he applied the patch partially - I think there is a problem with some of the files). I applied the patch to 6.x-3.xdev. Someone can help me? Thanks in advance.
Comment #57
j0e CreditAttribution: j0e commentedperhaps the dev version of views was updated since this patch came out, and the patch would need to be updated to match. that's what it sounds like at least.
Comment #58
dawehnerThe patch still applies clean here.
Comment #59
BWPanda CreditAttribution: BWPanda commentedI just tried to apply the patch from #45 to the latest dev version of Views 3 and got the following:
Comment #60
BWPanda CreditAttribution: BWPanda commentedHere's an updated patch of the changes from #45. I've tested and it works on my site.
Comment #61
dagmarJust as reminder. Like #1052312: Pluggable Breadcrumbs we have to find a solution to integrate the translation plugin with the multiple items defined per hybrid filter.
Comment #62
BWPanda CreditAttribution: BWPanda commentedHmm, this patch doesn't seem to work with date fields... They just default to Jan 1st of this year.
Comment #63
dawehnerSo in general the date module filter handler has to be changed, too. If you create a new version of a module it's not always impossible to not create some kind of api changes/additions.
Comment #64
BWPanda CreditAttribution: BWPanda commentedAnother thing I've noticed, the exposed group filter is being added into the exposed form just before the Submit button HTML...
See screenshot:
1 - Is where the exposed filter should be output,
2 - Is where it is incorrectly output
Comment #65
Shadlington CreditAttribution: Shadlington commentedSubscribing
Comment #66
Shadlington CreditAttribution: Shadlington commentedI LOVE this patch... It works great.
Can't wait for it to get committed.
Comment #67
jmolinas CreditAttribution: jmolinas commentedpatch wont work on views 6.3.x-dev got the following:
Comment #68
Shadlington CreditAttribution: Shadlington commented#67: I patched #60 against a fresh 6.x-3.x-dev yesterday and it worked fine...
Comment #69
dawehnerThis might not apply against 7.x-3.x
So take sure that you test it with drupal6.
Comment #70
klonos...amazing feature! Just put it into good use ;) Thanx people!
Comment #71
Shadlington CreditAttribution: Shadlington commentedIn light of http://drupal.org/node/646284#comment-4381712 this may have to be reworked as a separate module.
Comment #72
jvdurme CreditAttribution: jvdurme commentedWhat an amazing feature here. Just what I was looking for. Thanks a lot.
It however, does not seem to be compatible with sortable columns. When I select e.g. a custom "greater than" operator from the select list and filter, it works. But when I click then on a column header to sort that particular column, one of the filters jumps to "Any" and the message displayed is:
Otherwise, great tool!
EDIT: here is the fix for this! #1188828: Exposed filters mess up click sortable columns
Comment #73
jvdurme CreditAttribution: jvdurme commentedAny chance this will become a separate module?
The patch works pretty fine, but upgrading views with security updates will become a hassle like this.
Comment #74
bojanz CreditAttribution: bojanz commentedIf someone wants to work on it, then yes.
Right now the chances of it being committed to Views itself are slim.
Comment #75
jvdurme CreditAttribution: jvdurme commentedThen I subscribe for the module ;-) Thx for the reply!
Comment #76
Countzero CreditAttribution: Countzero commentedDoes it really work in 6.x-3.x - users seem to obtain random results ?
If so what should be done to bring this into 7.x-3.x ? Is there a project started to provide it as a separate module ?
I tried to transform an interval filter (on integer values) into a select element with hook_form_alter, but I end up with the "Illegal choice detected" message each time, whatever I try in the submit function. Any hint on how to get rid of it (and the underlying problem, of course) would be
welcomeinvaluable.Comment #77
dawehnerUsers seems to post random comments,
@countzero
This would be really hard to implement as seperate module, but feel free to waste development time.
As long this is not done in 6.x-3.x it will not land in 7.x-3.x either. Did you already tested it on 6.x-3.x, hopefully yet.
Your personal support issue is ignored on this issue.
Comment #78
Countzero CreditAttribution: Countzero commentedAs I don't have the Views API knowledge level to help on the original issue, I was just suggesting another approach via form altering, but I understand this doesn't seem a good idea.
So as of now, one has to write a custom filter handler to achieve an interval based dropdown exposed filter. Right ?
Comment #79
dawehnerYes you should write a custom handler.
Comment #80
tiw CreditAttribution: tiw commentedSubscribing.
Comment #81
Countzero CreditAttribution: Countzero commentedJust in case anyone is interested with an example of an interval filter handler for 7.x, mine is mainly functional : http://drupal.org/node/1239866. You may ask questions in this issue if the maintainers agree, and I'll try to help. Maybe I'll write a doc page if there is demand and I manage to find the time.
Comment #82
achtonSubscribe.
Comment #83
jvdurme CreditAttribution: jvdurme commentedHi there,
when this patch is applied, when I render the exposed form, it seems that the grouped items are squeezed inside the submit button div, like this (I omitted some html code for clarity):
I believe this is resulting in some issues with form elements weights/order that can't be adjusted even in views-exposed-form.tpl.php.
Also noticed that when I omit the $button variable from views-exposed-form.tpl.php, the Hybrid Filters also dissappear. So somehow the hybrid filters are displayed together with the submit button?
Does anyone know how I can fix this?
Thanks!
Comment #84
chinita7 CreditAttribution: chinita7 commentedSubscribe
Comment #85
jvdurme CreditAttribution: jvdurme commentedJust to confirm that the patch in #60 works flawless in Views 6.x-3.x-dev. Had to patch manually (copy/paste) due to some Views updates, but the hybrid exposed filters work.
As this works, can it be implemented in Views 6.x-3.x-dev?
What else has to be done in order to implement it? Can I help?
Comment #86
dawehnerOh that's good to hear. If you want to help here, please test it with the different kind of filters and see whether it works as expected.
Comment #87
jvdurme CreditAttribution: jvdurme commentedThen that's what I will do then. :)
Gimme a couple of days to testdrive this and I'll get back here.
Comment #88
chinita7 CreditAttribution: chinita7 commentedI just tried the patch #60 on 6.x-3.0-rc1 and it works like a charm.
I was struggling to achieve this feature for weeks for my age filter which is computed cck field. I hope it will be implemented in the 6.3 version.
Thanks a lot !
Comment #89
jvdurme CreditAttribution: jvdurme commentedSo I've tested it a bit and the issues raised by previous posters, remain:
The error message I get is:
warning: mysqli_real_escape_string() expects parameter 2 to be string, array given in /var/www/devel/includes/database.mysqli.inc on line 329.
And the mysql code executed is:
Node:Id works
Node:Title works
Numeric filter works
String filter works
So I guess there's still a bit of work. If someone is willing to fix this. I'm not experienced enough to do this.
Comment #90
Becker-and-Becker CreditAttribution: Becker-and-Becker commentedHello,
I tried this patch on 6.x-3.0-rc3 and there seems to be an issue on the views_handler_filter.inc part. Everything else seems to patch fine according to netbeans. Is it possible to get a patch for the lates rc3 version of views 3. Thanks.
Comment #91
jvdurme CreditAttribution: jvdurme commentedThe patch will probably start failing upon newer rc and dev versions because of too many changes. Just do as I did, and manually copy paste the new lines from the patch into the correct location in the files to be patched. All file and line number info is in the patch. It's a bit more work, but it works.
Comment #92
dagmarMy last patch of 2011 :)
I have been working in this patch during all this week, after reading several comments and because Drupal 7 is out and established, I have decided to port this patch to Views 7.x-3.x and when it be ready back port it to Drupal 6.
Here are some good news:
First, this patch is ready for testing, I did some tests and seems to be working fine.
Second, I found a way to solve the problem @dereine wrote in #63. This means, we don't need anymore port contrib modules to get this stuff working.
Third, I spent a lot of time documenting how this patch works, I know, it its a lot of code and I tried to make this easy to understand for other developers. However, my english is not perfect would be nice to have a review from people that really knows speak english.
Also, I have solved some issues with the templates, In the D6 version, some empty fields were rendered in the form, now the group filter replaces in a fashion way the exposed filter.
There are a few items missing yet.
First we have the translation problem, due groups are saved in a nested array translations plugin is not able to "see" the strings that have to be translated, I didn't spent time trying to port the translation plugin that I wrote for pluggable breadcrumbs, but if someone found and elegant solution (and with less lines of code) would be really nice to have. If not, we could provide a drupal_alter to translate groups, anyway is not too hard to do.
Also, we need some tests, specially with some weird filters (I'm sure a lot of testers can find ways to break this new feature, so please do it)
To people that wants to test this patch, just download views using the git instructions
Download the patch and apply with
And Please! please! don't put +1 for this, we know this feature is pretty cool, but use the new green "Follow" button at the top of the page.
Happy new year for all.
Comment #93
dawehner...and a value
operating small, so it's clear that this is the current sentence
which group they want to apply. Views will filter the ... to the defined value.
*standard
in another ... between ... and a group
Didn't we got rid of that in d7, maybe you should change it according to the other parts
... and a value
Comment #94
klonosThe patch worked fine for me too. Thanx for your hard work and all the time spent on it Mariano ;)
I'd like to express a couple of ideas I had on improving the hybrid exposed filters (let me know if you think this is off topic and I'll start a new issue):
How about supporting letter ranges as well besides numbers? For example, one might want to split an alphabetically sorted list of names/states/whatever so that they are presented in sets like so:
a-g (lower than or equal to g/G)
h-k (between h/H and k/K)
l-p ...
q-v ...
w-z (greater than or equal to w/W)
The check (query) should be performed on the first letter(s) of the field in question. Things that come to mind as something we'll eventually have to address are capitalization (case sensitivity), i18n and the need to be able to split sets based on more than only the first letter.
- Capitalization could be taken care of by either providing a "case sensitive" checkbox or by allowing values to be entered like so:
aA-gG
hH-kK
...
or the opposite (Aa-Gg, Hh-Kk ...), or even with some kind of "wildcard" like a*-g*, ...
- i18n would definitely be a tricky one. Should we define different sets of filters per language? I honestly don't know.
- Lastly, one might need to split a certain starting letter into two or more sets (if their db has a lot of entries starting with that specific letter):
aa-am
an-az
...
That's why in my suggestion I state that the query should be against first letter(s) of the field entry.
Another idea I had is to make the filters "smart". Instead of simply providing the option for the user to define specific filter sets, how about we also allow them to simply define the number of sets they want the drop-down to have and let the sets be automagically/dynamically calculated. These calculations would be:
- count the total of records
- divide the total by the number of desired value sets defined by the user
- split the records in sets based on the previous calculation
- dynamically populate the drop-down with these values
Do you think these improvements would be useful enough that they worth to spend time and effort on? Let me clearly state that I think that by no means should we postpone this feature request here on account of any of my ideas.
Comment #95
dagmarFirst to all, @klonos, it seems topic for a new issue.
Ok. Strings fixed. But I added some advanced help, so please take a look again.
The main change in this patch is the validation function. I modified it because it is not enough check !empty() for values that are arrays.
Also I did more tests and can confirm that this works properly with HAVING statments, (this came from the old #39 comment)
I just copied from another piece of code of admin.inc arround the line 3555, so I'm not sure if this can be done in a more Drupal 7 way.
Well, I'm quite conformable with this patch. Please do your own tests and provide feedback.
Comment #96
Marc-Antoine CreditAttribution: Marc-Antoine commentedFirst of, this thread is officially declared epic, be proud of yourselves ppl!
@dagmar
Sounds great so far, but it really needs some layout explanation (all I could see was some text inputs, I had to guess how to work things out)
Also, it looks like the 'null' label is gone from the radio widget type, leaving only the radio button on top of my list.
Tested using an integer field, and it runs smoothly.
Comment #97
dagmar@Marc-Antoine thanks for you comment.
I'm not really sure what do you mean with "layout explanation", maybe a better description of how to configure the hybrid filters?
I cannot replicate the 'null' stuff for radios, probably is a bug but I need a step by step explanation to replicate the problem.
I'm attaching a set of images that illustrates how to use this patch. In my opinion the new "Build group" is not enough visible and probably advanced users of views will not see the new feature due it is hidden all behind a simple checkbox.
I have also rerolled the patch since it didn't apply cleanly anymore.
Comment #98
imclean CreditAttribution: imclean commentedThis is a great feature and the patch in #95 works well for me. Thanks for all the work!
I can imagine there could be a few of these, but I have a particular use case which isn't quite working as expected. Using the values from a grouped filter I'm trying to populate the equivalent non-exposed filters of a different view using the session variables Views uses.
e.g. Minimum Price field using a select list
Title: 100
Operator: greater than or equal to
Value: 100
Title: 200
Operator: greater than or equal to
Value: 200
The value of the select option isn't actually the value specified, it's an internal value which I suspect is auto-incremented for the field (1,2,3 etc.). It's this value which Views stores in the session variable when "remember" is set. Presumably this is by design, but could there be an option to use the value specified in the config instead?
Comment #99
dagmar@imclean: I'm not sure if what you are saying is that you found a bug, or something that you suspects that doesn't works as you probably expects.
The 1, 2, 3 that hybrid filters save in sessions is required because there is not a easy way to save something like:
Views uses an 1 to represents the 3 things (title, operator and value) and this is what is saved into sessions. But when the 1 is loaded from SESSIONS it is converted again to the original set of operator|value.
Maybe a solution for your use case is use a hook, like hook_views_pre_execute, to load the values of the session and set the values for your non exposed filter.
Another solution could be make hybrid filters non exposed filters too, but I don't see a good reason to do this beyond the possibility to reduce a set of operator|value into a single number.
Comment #100
imclean CreditAttribution: imclean commented@dagmar, yes I suspected that would be the case. Non-exposed hybrid filters wouldn't solve my problem as the indexing would need to be the same. This can't be guaranteed as options can be added and removed.
Good suggestion, thanks, I'll give this a go.
Comment #101
punges24 CreditAttribution: punges24 commentedDoes anyone have the hybrid-filters patch already patched into views that I can download? I tried to patch it myself but it did not work for some reason.
Thanks
Comment #102
tim.plunkettAll defaults that are booleans should be:
This makes sure it exports correctly.
See above.
Split these onto multiple lines.
Maybe renamed this to show_exposed_form?
Why not use container with attributes instead?
Missing a full stop.
Missing full stop.
Needs a doc block
This is because of the new reserved group 0 for contextual filters? Perhaps there should be a constant for this instead of hardcoding 1 throughout views.
Missing full stop.
Shouldn't these still be arrays with 'default' as a key? And 'bool' => TRUE like above if the default is a boolean.
Missing full stop.
Missing full stop.
"value form $row" should be "value from $row", also missing full stop.
The sentences don't all need a line break, wrap it as a paragraph at 80 chars and end with a full stop.
Could just be $without_children, children is already plural.
Comma after 'group', full stop at the end.
Missing full stop.
Could likely be a ternary, not important though.
This should probably be rewritten as the docblock
Needs a doc block
The duplicated checks for the $_SESSION variable, and the assignment by reference, are confusing. Could probably check once at the top and it would make the logic more obvious?
Maybe build out the attributes into a variable, and do it over multiple lines? Or build out the common parts before the foreach and add to it within?
Why flip? Needs a better comment
Convention is now '$foo = &$bar', but is this even needed? It's a short string and only used twice.
Split into multiple lines
Why not move this out a line and then use $ instead of jQuery for the .click?
Missing semicolon
split, not splitted
Missing full stop.
Missing full stop.
Comment #103
Marc-Antoine CreditAttribution: Marc-Antoine commentedLooking at your screenshots, I'm really surprised; your interface is way different from mine, so I decided to take some screenshots to help you understand the issues I was talking about.
Sorry for the french interface btw, I hope it doesn't bother you!
I used the current dev (7.x-3.x-dev) of views
EDIT: in the 4th screenshot I mention a possible label bug because there are some radio buttons at the end of my form, but I realized they where there to choose the 'default' state of the filter, so the real problem is only that Drupal doesn't seem to generate it's usual table display.
EDIT2: Also, it would be awesome to have a checkbox widget available, or a Better Exposed Filter compatibility?
Comment #104
dawehnerFor the interface issue just clear the cache so the theme registry can be rebuild.
Comment #105
Marc-Antoine CreditAttribution: Marc-Antoine commentedYou're absolutely right Dereine, I'm obviously still missing some Drupal mechanism knowledge.
And while I've got your attention, I just wanted to thank you for your work on this awesome module (I've seen your posts on most of the issue around here, impressive stuff o.o)
Back on our subject, the radio labels are still empty when I use the radio button widget, (please look at my new screenshots)
and I've noticed a bug when using the Better Exposed Filter module (which enable the checkboxes widget to my normal exposed filters), it says
Notice: Undefined index: filter-field_my_name_value in better_exposed_filters_exposed_form_plugin->exposed_form_alter() (line 467 of sites/all/modules/better_exposed_filters/better_exposed_filters_exposed_form_plugin.inc).
(these are the lines)
466 // Form element is designated by the element ID which is user-configurable
467 $field_id = $form['#info']["filter-$label"]['value'];
Here's the bug I created on their module's issue queue http://drupal.org/node/1431810
I hope this will help initiate a dialogue between developpers, because it would also be a great feature to have hybrid filters using checkboxes widget.
Comment #106
Marc-Antoine CreditAttribution: Marc-Antoine commentedforgot about my screenshots, here they are:
This only occurs for the radio widget, but the select widget displays view's default label
I tried creating a new filter,
I tried creating a new view
Comment #107
dagmar@tim.plunkett: Thank you very much for you review. I applied most of your indications, a few things didn't changed. I'm listing the reasons here:
No. This function is similar to expose_options().
Mmm, this is an override for the function defined in handlers.inc. I didn't created this function.
Probably yes, but I didn't found a better way to do this, and it pretty similar to how store_exposed_input() works.
I just follow the same convention that used in theme_views_ui_rearrange_filter_form().
@Marc-Antoine: Sadly I cannot replicate the problem with the radios.
Attached the patch with almost all the modifications suggested in #102.
Comment #108
tim.plunkettThe 'from' and 'form' should be switched.
Also, something weird is happening that I'm not sure is related to this patch.
If the views_exposed_filter_any_label variable is set to '', and the exposed type is set to radio and not select, theme_form_element_label runs filter_xss_admin and strips it out. I don't have time to see if that happens elsewhere in Views right now, but I thought I'd point it out.
Otherwise, it works wonderfully.
Comment #109
dagmarWell, guess what...? a new patch xD
Ok, the changes are this:
Ok, In my opinion, this is ready to go. I did a lot of tests, and all seems to be working fine, there is however a small change to the UI that could be done, by default the - Any - option is never selected, you have to click on it, and I defined the #default_value to 'All'. I'm really don't know what is going on here. But this is trivial and not a big deal.
I would like to see this in before March 3, 2012 (This feature is getting old, almost two years...) :-)
Comment #110
dgastudio CreditAttribution: dgastudio commentedError message
The value is required if title for this item is defined.
Comment #111
dagmar@kervi thanks for the feedback.
Seeing your snapshot I think you didn't cleared the cache after applying the patch. Can you confirm that this behavior is present after clear the cache?
If this issue is still valid, please give a bit more of information about what kind of filter is causing this problem.
Comment #112
dgastudio CreditAttribution: dgastudio commentedsorry, after clear cache everything seems working fine. thank u!
Comment #113
imclean CreditAttribution: imclean commentedBetter Exposed Filters support: #1431810: Better exposed filter displays an error when used with hybrid exposed filters
Edit: missed the link in #105. New patch anyway.
Comment #114
dagmar'old_any') was replaced by 'new_any')
Operator replaced by ===. I found a bug here, now the first time the form is rendered and user selects '- Any -' this setting is remembered.
So, this is almost a re-roll, with a couple of fixes.
Comment #115
tim.plunkettI'm only noticing one real problem:
I click to add a filter, and check the box for both a field to make a hybrid group, as well as content type. In alphabetical order, the field config comes up first, and I check the box to make it a grouped filter. When I finish configuring, I'm NOT taken to the config for content type, and hitting save will throw an error.
Not clicking the group checkbox, it works normally. Maybe something crazy with the $form_state?
Also, minor nitpick for the reroll:
This should be
'data' => variable_get('views_exposed_filter_any_label', 'new_any') == 'old_any' ? t('<Any>') : t('- Any -'),
for consistency.Comment #116
dagmar@tim.plunkett thanks for the review.
I can replicate the problem. However I can replicate the problem in the current version of views 7.x. Just try to expose a filter and you will have the same problem. Then I think this is not a bug produced by this patch.
So the question is, Do I have to find a solution for this problem in this patch, or is a different issue?
Comment #117
tim.plunkettYou are 100% right, that's a pre-existing bug.
I've opened #1461904: Exposing a filter prevents subsequent filters from being configured to address that, if you reroll with the last tweak, I think it's ready to go!
Comment #118
dawehnerI just tryed to input 0 into the fields, but the required didn't allowed me to do that, see screenshot.
The change fixes it.
I corrected the small thing in #115
All my manual testing worked fine!
Comment #119
tim.plunkettI think there is a further problem on top of #1461904: Exposing a filter prevents subsequent filters from being configured, even though that fixed other bugs.
After picking out two filters, and clicking configure:
The first filter submit shows "Apply and continue": https://skitch.com/plnktt/8gy2b/exposed-hybrid-content-d7
After exposing it, it still says that: https://skitch.com/plnktt/8gy2c/exposed-hybrid-content-d7
Finally, when clicking "Build a group of filters", it switches to "Apply", and no longer goes to the second filter. Also, the first two show "1 of 2" in the top right, and this says "2 of 2": https://skitch.com/plnktt/8gy4r/exposed-hybrid-content-d7
So whatever magic with
$view->stack
was fixed in the other issue, this needs it too.Comment #120
dawehnerApplied the technique from the other patch to this patch. It worked for me fine.
Comment #121
tim.plunkettYep, that last patch works 100%. You mentioned you wanted merlinofchaos to look at this, I'll also have someone from zivtech who hasn't seen this try it out to see if it all makes sense to them.
Comment #122
klonosI hate posting worthless comments, but seeing this getting so close to finally being committed makes me so excited! ...it's this issue's 2nd "birthday" in two days :P
Comment #123
tim.plunkettOkay, did some user testing with one of our themers, here's the feedback:
Instead of a checkbox "Build a group of filters", have two radio buttons:
"Single filter"
"Multiple filters"
"Single filter" being the current exposed filter, "Multiple filters" (or something similar) triggering the hybrid/grouping stuff like the checkbox does now.
In the table of settings, "Title" should be required, and renamed "Label".
In the default column, "Any" should be the default default.
Comment #124
tim.plunkettOkay, this addresses the default bug and changes the label. The required label is actually a bad idea, I think.
I also cleaned up some of the JS. I didn't yet switch to a radio button since there is Drupal.viewsUi.Checkboxifier but nothing for radios yet.
Comment #125
klonos...so, should we leave the switch from the checkbox to the radio button to a separate, followup issue? Please consider this because this feature really doesn't deserve to wait even more on this trivial UX thing.
Comment #126
dagmarI'm going to try to implement the radios on this weekend. We waited two years, we can wait a few more days.
Comment #127
tim.plunkettAlright, well I was really impatient so I went ahead and did it.
Discussed with a couple more people, I think the string changes make a lot of sense.
Attached is the whole patch as well as changes since #124.
Comment #128
tim.plunkettComment #129
dagmarHappy birthday issue!
Well, I think chx was right when he said that best ideas came up in the shower. I'm happy to announce a new feature in this patch, now is possible to use checkboxes for the widget, this means, yes I'm not kidding!, that you can apply different filters at the same time.
So this is how this works, by default, views manages multiple items at handler level. But doing some changes in th views::_build() function I found a way to submit several times the info of a exposed filter. Pretty simple, and seems to be working fine.
There area some problems with, how the view has to be configured to make this stuff work fine. For example, probably hybrid filters with checkboxes may go inside their own filter group and set the operator to OR in order to get mutually exclusive filters working together.
Also this addition needs a string review from, ejem, @tim.plunkett :P but I think this is a small change but powerful uses.
Oh, and probably find better way to define the 'default values' when the widget are checkboxes.
Attached the patch and an screenshot to illustrate the new addition.
Comment #130
monil-dupe CreditAttribution: monil-dupe commentedThanks dagmar for this patch and fixes and features you did.
Comment #131
tim.plunkett'choosed' should be 'chosen', use search and replace because there is more than one.
This should be a ternary for clarity, and a line break after it.
I would probably start the function with
$options = array();
, assign the array_filter to it, and then return $options;This entire set of changes in includes/view.inc looks like it needs to be refactored, there is a lot of duplicated code between these conditionals.
Comment #132
dgastudio CreditAttribution: dgastudio commentedi have applied the latest patch, but ui is totally not usable (cache cleaned).
Comment #133
JurriaanRoelofs CreditAttribution: JurriaanRoelofs commentedI'm trying to apply some of these latest patches to both latest stable and latest dev and all of the hunk are failing. Maybe someone can attach a zip with the patch properly applied?
These latest patches are for 7.x right?
Comment #134
dagmarYes, they are for 7.x. And probably you are right, the patch doesn't apply anymore.
I have been a bit busy past month, I will try to create a new patch in next days/weeks.
Comment #135
abtm CreditAttribution: abtm commentedAny progress on this? I am building a property portal. Operators like >= and <= will make it possible for users to define their search criteria, e.g. "min bedroom" and "max bedroom". Thanks.
Comment #136
dagmarRerolled. Re-Tested. Applied comments from @tim.plunkett in #131.
There is only one "TODO" besides the i18n stuff mentioned in #61.
The only problem I found is that default values for grouped filters with 'multiple items' option checked are not respected. So whatever you choose as default value in the checkboxes it is not applied.
If anybody can take care about this, I don't have more ideas to fix it. Or we can just remove the entire 'multiple items' feature and dealt with it in other issue.
Comment #137
dagmarI figured out how to make the multiple items work. Also remove items was not working properly, this is fixed too.
Well, it seems to be working fine. Besides the i18n problem, I don't see nothing else to fix.
Please provide your feedback.
Comment #138
abtm CreditAttribution: abtm commentedThanks for the patch dagmar. It solved a big problem of mine. It's working well apart from three drawbacks:
1. In the Grouped filters, value "0" can not be saved. My first option's label is "Studio" and its value is "0". Every time I go back after saving the settings, the value "0" is gone, and if I select "Studio" in the form to filter the result, an error occurs.
2. There isn't a way to customize the default label value "- Any -". So I won't be able to set it to "No min", "No max" etc.
3. If the minimum value is greater than the maximum value, the form is still valid but no result is found. (I thought I would be able to use rules to throw a error msg but there doesn't seem to be a way even after installing "Rules Forms Support" module.
Comment #139
dgastudio CreditAttribution: dgastudio commentedone more "bug".
after switch to "Grouped filters " there is no way to change exposed filter label.
Comment #140
dagmar@abtm: Thanks for your feedback.
I have fixed the item 1, but I think that 2 is task for Better Exposed Filters module or maybe implementing a hook_form_alter. Sorry I know that I could provide this directly from my patch, but you know, It a lot of code to review and I really want to get this in.
Related to 3, well, maybe a follow up after this patch gets in.
@kervi: I cannot replicate your problem. After you enable the exposed group, you can set the Label for the widget using the 'Label' textfield in the UI.
------------
So, This patch is 25Kb bigger than my last patch because it includes tests.
I wrote tests for string, numeric, in_operator and equal handlers. Date and combine filters tests are missing but we can add they as a follow up.
Tests helped me to discover some failures in the patch, that are already fixed in this version of the patch.
Also, I found some problems with the exposed form caching and the testing framework. Therefore a new flag was added in views_exposed_form to allow to disable the caching system when tests are running.
That's all. Daniel, is your turn now.
Comment #141
abtm CreditAttribution: abtm commented@dagmar: Thanks for making such a long patch! Is it going to be committed or do we have to apply it every time after updating this module? It did take a long time for me to apply it. :)
Comment #142
dagmarRe-rolled to reflect changes introduced by #1630136: Allow to clear the cache for exposed forms
Comment #143
dagmarTests passed. Assigned to Daniel to final review.
Comment #144
dawehnerAdded some screenshots used for the summary
Comment #144.0
dawehnerAdded a proper summary
Comment #144.1
dawehneradded screenshots
Comment #145
dagmarBTW, there is already included in the patch, docs for advanced help.
Comment #145.0
dagmaradded h4s above the screenshot
Comment #146
klonosThanx for the updated patch and screenshots+summary Mariano & Daniel!
...one thing though: I realize that though all of us following this issue got used to the term "hybrid", that's not so self explanatory when used in the UI. Though a lot better than "hybrid filters" I don't think that "grouped filters" does the job either. I think "filter ranges" describes it much better. What do you think?
Comment #147
tim.plunkettI'm going to give this a final manual test and review, then it can go in.
Comment #148
yultyyev CreditAttribution: yultyyev commentedI'm using #142 patch with filter "number rooms" (like in the issue), but I checked "allow multiple selection" (e.g. to filter the flats with 1 and 2 rooms) and I get view's query like this "myfield = 1 AND myfield = 2", so nothing is showing in view's results, the query should be like this "myfield = 1 OR myfield = 2". How can I get that?
Comment #149
dagmarYou should include the filter in its own group and set the operator of the group to OR (By clicking in the re-arrange option).
This is explained in the documentation of the patch.
Comment #150
dagmarI have included some tests for the UI.
The first patch is essentially the patch provided in #142 plus the new tests.
The second patch includes the fixes for the fails that the new tests discovered.
There is not changes in the main functionality.
Comment #151
dawehnerLet's get it in now, there are so many tests written for that, and many users tested this already.
@dagmar
Thanks for tons of your hours connected with this patch
Comment #152
tim.plunkettHahaha I was JUST testing this! Was about to RTBC :)
dagmar++!
Comment #153
tim.plunkettRerolled, all of the plugins were moved around.
Comment #155
tim.plunkettIt was trying to manually include view.inc, which is gone and its replacement is autoloaded.
Comment #156
klonosOMG!! Thank you, thank you, thank you. It's been so long that I've been patching my installations with this I can't believe it'll be in the next 7.x dev :D
Comment #157
Jackinloadup CreditAttribution: Jackinloadup commentedThank you dagmar, dawehner, tim.plunkett, bojanz, SuperXren, and BWPanda! Amazing results.
Comment #158
tim.plunkettRerolled for annotations.
Comment #160
tim.plunkettAh, it needed
protected $profile = 'standard';
Comment #161
tim.plunkettI tested this and it works, it was a pretty straightforward port.
So, I committed it: http://drupalcode.org/project/views.git/commit/8311f38
Comment #162
yultyyev CreditAttribution: yultyyev commentedSome trouble with this part of module (in Views 7.x-3.4)
I make some hybrid filters with checkboxes (rooms: 1, 2, 3, 4+), when I submit exposed form all works fine, but when submit none of checkboxes selected in this filter all works only on first page: in url there are none of arguments of this filter, but pager produce url like this viewspage?rooms[1]=0&rooms[2]=0&rooms[3]=0&rooms[4]=0&myotherargs&page=1 the second page of view's result is empty with error (wrong choise in filter) and checkboxes are selected all. When I remove wrong part of query "rooms[1]=0&rooms[2]=0&rooms[3]=0&rooms[4]=0" from url, the view show normal result page.
---
update: i have create an issue #1750914: "An illegal choice has been detected" error when using hybrid exposed filters.
Comment #163
dawehner@yultyyev
Please create a new issue for that. If not it will be incredible hard to be able to follow the issue.
Comment #164.0
(not verified) CreditAttribution: commentedno docs required.