I'm setting up a view that has as a "Taxonomy: Term" as an argument. Under the "Validator" options for the taxonomy term, I've selected that I want to validate for one specific vocabulary ("Aircraft" in my case). The resulting view basically works, but there are a few unexpected things happening that it seems could be fixed if the specified validator was used by the code in a few more places.
Specifically:
* If I select to view a Summary list when the argument is not present, the summary list contains all of the taxonomy terms used on my pages -- not just the taxonomy terms from the Aircraft vocabulary, which is what I'd expect (and which is far more useful to the site's users than a list where most of the links go to invalid entries)
* Similarly, standard queries (not just summary queries) should also take into account any specified vocabularies.
* A third issue was just fixed by #998400: Argument validator "Term name converted to Term ID" ignores Vocabulary selection.
In checking into the code to fix these issues I also noticed that:
* views_handler_argument_taxonomy.inc is basically unused, because taxonomy.views.inc doesn't list it as the handler
* the title function in that handler doesn't include handling for numeric arguments -- for which presumably the title should be the actual taxonomy term name, instead of its tid
I'm attaching a patch that addresses these issues.
| Comment | File | Size | Author |
|---|---|---|---|
| views-taxonomy-use-validator-vocabularies.patch | 3.64 KB | Nephele |
Comments
Comment #1
dawehnerMove to 6.x-3.x . New features are not added at the moment to the 7.x-dev version first.
Thanks for the patch
Comment #2
merlinofchaos commentedWell, obviously the patch won't apply to 6.x so that right there shoots it down. There's also some coding style issues (spaces around all . operators, for example) that would need to be addressed.
However, there's a bigger issue. This basically hacks a direct lookup from an argument handler making assumptions about argument validators. This is probably not the right way to do it. That means that using this same validator on *another* tid argument from something else
Instead, we need to be able to create a way for validators to affect the query. Which is something I've actually had in the back of my head for a long time, but have never done. Particularly when validators make transformations to the argument, they need to be able to affect the output of summary queries to untransform.
So: In order to accept this patch, it needs to crate methods on validators for summary query and output and allow validators to make appropriate changes. Then the *validator* can do the filtering.
Comment #3
merlinofchaos commentedShould've marked this needs work on my last review.
Comment #4
mustanggb commented