Filters and arguments basically do the same work: they apply a WHERE clause to the query.
With the exception of a very small number of argument handlers that do something different, we are duplicating code every time we write a filter and an argument for a table field.
I'm aware of the issue (and patch) for taking a filter value from the URL, but I think for 8.x/Views in core we should rethink this a bit more deeply.
Conceptually, I see this as being two different handlers:
- filters, which can take their value from any of:
-- fixed input
-- form input
-- URL path components
- arguments, which specify that the view is aware of path elements beyond its base. There would be very few argument handlers remaining:
-- "make this value available to filters" (which takes care of argument validation ready for the filter)
-- Global:Null
-- taxonomy term depth
-- ... and any other existing argument handers that do more than just filtering.
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | drupal-1668024-15.patch | 8.54 KB | dawehner |
Comments
Comment #1
dawehnerJust for reference: #357082: Pull filter value from an argument?
In general we should also look what we are doing with the different kind of plugins/advanced stuff on top of arguments
* glossary
* validation of the values
* what happens if no argument is present action
* default arguments
* summary plugins
These are features which aren't supported by filters at the moment
Comment #2
tim.plunkettComment #3
joachim commented> * validation of the values
Should we move that to something that filters can use too? I'm thinking of when we have exposed filters that are just a textfield for an entity ID, say (as with Entity Reference module).
> * what happens if no argument is present action
That should definitely stay as something that's attached to each argument.
> * default arguments
Same too.
> * summary plugins
> * glossary
I know less about these two -- I haven't used them since Views D5 I think!
Comment #4
xjmI've wanted this since like 2008.
Comment #5
tim.plunkettI had an idea about this on the subway this morning, not sure if it'd be more or less confusing.
Basically, we already group regular filters with exposed filters. Why not have contextual filters in there the same way.
The big change here would be that order is important to contextual filters currently. But, we already have the "Views Or" grouping ability, with the 0th group reserved for them.
So telling a regular filter to become exposed would visually move it to that group, and they could be reordered as normal.
If what I described makes no sense, I could probably make a mock-up...
Comment #6
tim.plunkettDetails to come.
Comment #7
tim.plunkettBumping for myself.
Comment #8
joachim commentedI'm not sure this is just a UI thing, as one of the consequences of this would be that we can ditch a ton of code in argument handlers that duplicates the corresponding filters. Though the first part of the work would indeed be figuring out how to present this all in a clear way to the user.
Comment #9
xjmYeah this is a fundamental API change. :)
Comment #10
dawehnerAs we talked before especially on badcamp, we should first just try to fix the UI and embed
contextual filters as they would be filters and provide all the options.
The next step, which would maybe even fall under the feature freeze category from my perspective,
would be then to actual figure out how to merge them.
Comment #11
xjmHmm, nothing about this is a feature, and I don't remember coming to that conclusion... Also, I'm confused how making a UI change without the API change is worth the effort? Wouldn't we be writing a bunch of code that we would just throw out?
Comment #12
xjmWhat I recall is deciding to do this during feature freeze since it is a major API change that is not blocked by FF.
Comment #13
tim.plunkettThey are currently fundamentally different plugin types.
They are essentially filter plugin that require a corresponding default argument plugin.
If we were to try and rewrite the API first, we'd have to deal with broken API tests as well as UI tests.
By moving it around in the UI first, it will be easier to keep a patch green, and might also make it clearer how the plugin code should change, since they will become so similar to the exposed filters.
I think what @dawehner mean was that is can happen "during" feature freeze, aka before code freeze.
Comment #14
xjm:)
Comment #15
dawehnerSo here is a first version which sadly doesn't allow you to save the actual data due to a fatal.
Comment #16
tim.plunkettComment #17
dawehnerA clear sign that we need tests.
Comment #18
dagmarSo, is this a duplicate of this #1831220: Improve the UX for creating filters for a view?
Comment #19
tim.plunkettI think #1831220: Improve the UX for creating filters for a view can be a follow-up for this, actually. It'd be best to just get this working first and then revisit the exposed/contextual/grouped filters UX at once.
Comment #20
xjmIf we want to do this in D8 we should revisit it soon, I think.
Comment #21
joachim commentedSee also #357082: Pull filter value from an argument?, which is for D7 Views, but has a lot of good ideas for this.
Comment #22
dawehnerThis will seriously not happen in Drupal 8.
Comment #23
xjmComment #23.0
xjmUpdated issue summary - fixed bullets
Comment #24
mgiffordComment #25
mgiffordComment #26
catchThis looks like it could theoretically happen with bc, so moving back.
Comment #30
giorgio79 commented@jwilson3 had a nice and perhaps more radical approach too at https://www.drupal.org/node/357082#comment-7233586 (#357082: Pull filter value from an argument?)
Comment #32
giorgio79 commentedAdding Facets too as they are modding the WHERE clause as well. Facets is growing fast with Search API https://www.drupal.org/project/facets
Some more info on the current state of Facets and Views (they don't know much about each other) https://www.drupal.org/project/views_data_export/issues/2789531#comment-... via @drunkenmonkey
Comment #33
giorgio79 commentedOr, perhaps Views could just provide an API for modding WHERE clauses and then filters and arugments can be removed from core, similar to how Facets is approaching the problem #3031581: Provide JavaScript API for facet widgets
Comment #34
geek-merlinHmm, we're having scope creep here, and i think it's good here.
We started with the idea of a UI hack to unify (regular|exposed) filters, but imho (i dedicated a whole module to this) turned out to be hard.
> Or, perhaps Views could just provide an API for modding WHERE clauses
Yes i'm all for exploring this question. Some random thoughts:
* I think i remember in one of the "entity-access-NG" issues that @bojanz made an abstraction of views-condition and EntityQuery-condition.
* If a filter provides options of "how to drill deeper", that's just what facets does.
Comment #35
joachim commentedYeah, this should be moved out of the views UI module and into views itself.
Comment #46
anybodyLooking at this 14 years later, I still think this was an early UX misconception in Drupal Views that has never been resolved.
This still affects UX / SBX in views a lot, because it's harder to understand and hard (or even impossible with OR) to combine with (exposed) filters.
Several modules tried working around the root cause in the past, like
but it was never really user-friendly, because the root cause can only be fixed in Views itself.
So I'd very much like to bump this once again, because I think all levels of Drupal users know about this flaw and in times of AI I'd hope we'd possibly be able to finally resolve it.
Thank you very much @joachim for creating this issue in the very early days, I think it still hits the spot. What do you all think about it?
Comment #47
joachim commentedI've actually been giving this some thought lately.
Now that Facets 3 uses Views filters, I'm not sure we need to do anything special for facets, but I'll ask the Facets maintainers what they think.
I'll try and find time to work on this in the near future -- but just to say, I won't work on any MRs that include LLM work.
EDIT:
Actually, now I think about it some more, maybe if we define a new Filter Value Source plugin type, and in Views we have 3 plugins fixed / exposed form / argument, then Facets module could add a 4th plugin for facets, and then facets filters could use the same Views Filter plugins instead of duplicating all the filters for all fields.
Comment #48
anybodyWhao, thank you very much @joachim! That sounds super promising and I love to hear someone as experienced as you is planning to do it!
Totally fair
That makes a lot of sense to me. The important thing in my eyes is combining these things and thereby allow the combination (AND / OR groups) and easier handling and understanding in the UI. Arguments and filters should just be value sources.
Very much looking forward to this! In my eyes, it will be one of the most important improvements to Views in the last decade.
Comment #49
joachim commentedI've started the basics of this, and pretty quickly realised that the hard part is going to be the *interactions* between the different filter sources. It's not as simple as "you select one source, and that's what you get".
Because currently, filters effectively have two sources (even though they're not called that), fixed and exposed, and they interact in complex ways.
Here's what I've determined are the possible combinations (and please let me know if I have missed some!)
A. Not exposed. Admin options must have a value -- Can (weirdly!) choose 'select all', even though that effectively means the filter does nothing! Though doing that is glitchy in some filters, e.g. Published (takes first value), content type (includes special 'all' value in the query)
B. Exposed. Don't select a value -- Exposed filter has no default, all values to select from.
C. Exposed. Do select a value -- This is used as a the default for the exposed filter, all values to select from.
D. Exposed. Don't select a value. Use 'Limit list to selected items' -- This is a DEGENERATE CASE! The exposed filter shows no values!
E. Exposed. Do select a value. Use 'Limit list to selected items' -- exposed filter available values are from the config. There is no way to set up default values. Effectively, the available values are the default that is already applied.
I'm considering how we handle this when arguments are added as a 3rd source.
One idea I've had is that we consider the sequence of sources to be a pipeline, through which the filter values pass, where each source can do one of the following to its incoming values:
- REPLACE: the previous source's filter values are ignore, and the current source's filter values are used and passed on
- REFINE: the previous source's filter values are the values from which the current source can select
That works as an abstraction for the current interaction between fixed/exposed, but I'm not sure arguments will make sense with that.
An alternate idea is that it's not a pipeline, but instead the question is 'where does a source get its possible values from?' Do you get them from the underlying field, or from prior filter source?
Comment #50
anybodyThanks @joachim good point! I think we'll need a UI sketch here to find a good and understandable UX. My personal opinion is, that a pipeline would be hard to understand. But TBH I think we'll need something visual first.
My tendency goes into the direction that a filter has a radio or checkboxes to allow certain sources. I think it might even be fine to make them distinct (e.g. URL parameter vs. URL argument) or hard-code an order of precedence.
Thinking about this a bit more I think we definitely need to invest some time into UI / UX concepts and research for past issues with the existing implementation, because we should give as much flexibility as possible in the future, use-cases can be complex.
Should we maybe ask the UX team to join early?
Comment #51
anybodyPS: Do we know any other software that provides something similar and maybe already solved this better or could be challenged?
Comment #52
joachim commented> hard-code an order of precedence.
Yes, I think the order should be hard-coded. I think the only order that makes sense is:
fixed -> argument -> exposed
If you have all 3, then your basic view has the fixed filter values. You can override those with an argument. And once you're on that path, the user's exposed form values go last.
> My personal opinion is, that a pipeline would be hard to understand.
I wouldn't necessarily present the pipeline in the UI. This is mostly about how we conceptualize it in the code. But I agree, the UX is going to be really important too.
Very basically, I was thinking we'd put each source into its own details element. At the top of each section, we'd have the control that sets how the values from the previous source are handled into this one:
(credit: https://asciiflow.com )
> (e.g. URL parameter vs. URL argument)
Do you mean query parameters vs arguments? Query parameters only come via exposed filters, right, or have I missed another piece of functionality?
> Do we know any other software that provides something similar and maybe already solved this better or could be challenged?
I know of a query builder in Microsoft Dynamics, but I've not seen what it looks like.
Comment #53
anybody@joachim: All simply "YES"! :)
Perfect.
I think we should give it a try and once we think it's good enough or get stuck, ask the UX team?