In working on a bunch of the default views for project* for the d6 upgrade, I found myself needing to access the current value of some view argument while I'm processing a filter. Since filters are handled first, the $view object itself doesn't know its own argument values yet. I wrote a helper function for this that I originally put in project_issue.module, but it seems like something such as this would be valuable for anyone doing more advanced views hacking like this.
I wrote it as a standalone helper function that takes a $view object as an argument, but now it occurs to me that perhaps this makes more sense as a member function on the $view itself.
Thoughts?
Thanks!
-Derek
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 369505-3.argument_get_value.patch | 1.67 KB | dww |
| #2 | 369505-2.argument_get_value.patch | 1.46 KB | dww |
| #1 | 369505-1.views_get_argument_value.patch | 1.81 KB | dww |
Comments
Comment #1
dwwHere's the version as a stand-alone helper. Let me know if you want me to re-roll this as a member function on view objects themselves.
Comment #2
dwwBetter yet -- now as a member function on the argument class itself.
For example, the callsite in project_issue would look something like this:
Comment #3
dwwIf we already have the value, we can just return it without processing anything.
Comment #4
merlinofchaos commentedCommitted! Good work on this!