I'm trying to programmatically add [fields / filters / ...] to a user-defined view, by doing something like :
$view = views_get_view('the_view');
views_view_add_filter($views, params...);
views_view_add_field($views, params...);
$result = views_build_view(whatever...)
This of course fails because the new [fields / filters / ...] lack the additional information that's provided in _views_sanitize_view.
So I should call _views_sanitize_view before the final views_build_view :
$view = views_get_view('the_view');
views_view_add_filter($views, params...);
views_view_add_field($views, params...);
_views_sanitize_view($view);
$result = views_build_view(whatever...)
This then fails because the [fields / filters / ...] that natively belong to the view are already "sane", and get messed up inside _views_sanitize_view
This patch modifies _views_sanitize_view so that it does its job only when actually needed (it also "promotes" the function to the external views API by removing the initial '_' in its name)
PS :
- for the record, the need comes from this patch for CCK / nodereference
- I'm aware of the _query_alter hook - it's just that for this particular need it would make my life much more complicated (and be a performance blaster)
| Comment | File | Size | Author |
|---|---|---|---|
| views_2.patch | 3.35 KB | yched |
Comments
Comment #1
yched commentedOK, i've been a little dramatic in my last remark :
It appears I can in fact rather painlessly use hook_views_query_alter for the needs of the patch mentioned above.
Yet this implies a lower-level coding style, which is less elegant (well...), and seems more 'fragile' wrt views.module implementation :
as opposed to
So, just to sum up : not _needed_, but so much cleaner it might be worth considering ?
Comment #2
merlinofchaos commentedThis seems completely reasonable and this will get committed.
Comment #3
merlinofchaos commentedComment #4
(not verified) commented