Drop automatic view creation
| Project: | Nodequeue |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Nodequeue by default creates a view for every nodequeue that exists. In my experience, though, that view only causes me headaches. I cannot use it directly, because the name is nodequeue_X, and if I try to export that view to code in my own module with that name then Views breaks. So I have to clone it, rename it, and disable the original view. So I now have twice as many views as I actually need, including a dozen that are disabled just taking up screen space.
Of course, that cloned view has a whole bunch of stuff in it by default I have to rip out, like the name and the mundane listing page, because I have never once had any use for it. So I'm better off just building the view from scratch and ignoring the nodequeue-based ones. Which means I still have a dozen views sitting around doing nothing but taking up space and distracting me.
And of course none of these problems are intuitively obvious, so every time I work with someone new I have to re-explain to them why to avoid the nodequeue-provided views like the plague, usually after they've already modified them so we have to take the time to clone, rename, and clean them up.
So can we just eliminate the problem by eliminating the never-useful-in-my-experience default views? Please?
#1
I see what you're saying. I once proposed replacing these with a single view that accepts arguments.
I'd rather make the generation of default Views a configurable option since it saves casual users a lot of time. I'd be happy to review a patch that makes this a simple checkbox under the main nodequeue settings.
Also, I'm not sure what you mean by :
"I cannot use it directly, because the name is nodequeue_X, and if I try to export that view to code in my own module with that name then Views breaks."
How and why does it break?
Thanks!
#2
Probably because having multiple views with the same name in exports is bad. But at that point you should be cloning the view. =)
I think the automatic view generation is necessary to have available, but I have no issue with turning it off.
#3
Turning it off would be good enough for me, especially if it's off by default. Or a single argument-based view would be easier to disable once and then ignore. That may even be the best approach, because then I can just disable it once on the site and be done with it. :-)
And yes, it breaks because when you have two views in code with the same name, mysterious bad things happen. But if you start with that view there and ready for you, then it's soooo tempting to just tweak that, and you don't realize until much later just how much trouble you cause yourself that way.
#4
what about a variable called
'nodequeue_automatic_views_generation' and this is placed in hook_views_default_views.
this should be all, so the developer can disable if needed
#5
Hello everybody.
For everyone trying to store his overridden default views in code while avoiding the clone-disable trick above, there is a views hook that can help.
It's hook_views_default_views_alter(&$views) and although undocumented it's use is similar to this hook_views_default_views().
An implementation could go like this
<?php/**
* Implementation of hook_views_default_views_alter().
*/
function xxx_views_default_views_alter(&$views){
include_once('export_tab_dump.php');
return $views;
}
?>
Where
xxx is your views code holding module and
export_tab_dump.php is the output for the views export tab for a view.
I have tested it with nodequeue as well as with other default views and works nicely.