Allowing recursion
| Project: | Viewfield |
| Version: | 5.x-1.5 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
The current code in the viewfield blocks any recursion (node inserting a View that is specifically reinserting the node). The current solution seems to be the right choice, but in some cases like: http://oyoaha.com/node/16 we use the inserted view to aggregated cck fields from this node and display them with bells and whistles, aka a light box. With the current "no recursion policy" our method fails, so I implemented a more sensitive anti-recurrsion scheme which can be adjusted at the level of recursion desired (for now the level is hard coded inside the _viewfield_nodestack function and set at one level of recurrsion). The patch works great as is, but I feel it needs to have some administrative option to specify the recursion level.
I will be more than happy to implement this feature, which is why the patch is marked as "code needs work"). We use this module+patch as a part of the workflow for our oaliquid module (fyi: we're still working on documentation but can explain its use if needed): http://drupal.org/project/oaliquid
| Attachment | Size |
|---|---|
| recursion_viewfield.tar_.gz | 3.7 KB |
#1
I can confirm this patch "worked for me" - I've recommend people use it when combined with view_of_views - I would like to see it included in a release of viewfield (which is a critically useful module I think)
Cheers
Mark.
#2
The code has now changed significantly. Also, a patch only requires enough comments to explain how it works.
#3
Hi there))
Just 2 very quick questions:
- This issue is reported against view_field 5.x-1.4.
Will the patch work equally fine with the current version 5.x-1.5? Can the patch be applied without further changes?
- Why is the patch it not included in the official view_field release?
Is there something one should be aware of when installing the patch?
Many thanks & cheers!
#4
I'm using version 5.x-1.5 and if you add
_viewfield_nodestack_pop();to your argument handling code, you can stop it from excluding the current node. The assumption would seem to be that you are taking the responsibility upon yourself to ensure you are not including the viewfield itself as one of the fields of your nodes ;-)
Or something...
Anyway, I'm not sure if that's the intended usage but it seems to be doing the trick for me.
#5
The attached patch provides a field setting that lets administrators decide whether recursion is allowed in the viewfield. Recursion is disallowed by default.
My use case is a view that uses the argument node in a relationship, without actually using that node in the view's output. Without a patch, the view's output is always empty when used in a viewfield.
#6
will this work on viewfiled 5.1.5?
#7
IMHO, this would be great to include as a feature, off by default. My use case is to display a gmap view (a map of the current node location).
#8
I am unable to apply this patch to the latest 6.x-1.x-dev version. Is it me or the patch file?
Running CentOS 5.2
patch <viewfield-recursion-165321.patchpatching file viewfield.module
Hunk #1 FAILED at 82.
Hunk #2 FAILED at 104.
Hunk #3 FAILED at 153.
Hunk #4 FAILED at 200.
Hunk #5 FAILED at 485.
Hunk #6 FAILED at 493.
Hunk #7 FAILED at 503.
7 out of 7 hunks FAILED -- saving rejects to file viewfield.module.rej
#9
For the record, I applied the patch manually and it works great for my use case, showing a gmap map of the current node. I have changed the status to reviewed and tested by the community. Community, in this case, should be defined as someone who knows little.
#10
I manually patched w/ #5 against 6.x-1.x-dev and it seems to work except for one thing.... it doesnt save my default arg's now.
Thats the only bug I've found so far.
#11
My mistake... I wasn't checking "Use a common default value for all nodes if the user does not override it on the node form."
Here is the module and the patch from what I have against D6.
#12
Would it be possible for you to re-roll this patch against HEAD? I'll review it and perform further testing.
Jer
#13
Duplicate issues 418164, 290023, 273084.
#14
I came back to this again because I needed it again, but now the dev is a lot different than the patch and it will be difficult to patch manually even (for me anyways).
I'm kinda sad this didnt make it in way back when it actually worked. If someone has time, please take a look at this.
#15
Why not comment out this code altogether?
///**
// * Implementation of hook_views_query_alter().
// *
// * Prevent views from loading the node containing the view.
// */
//function viewfield_views_query_alter(&$query, &$view, $summary, $level) {
// global $_viewfield_stack;
// if (!empty($_viewfield_stack)) {
// $query->add_where('node.nid NOT IN ('. implode(',', $_viewfield_stack) .')');
// }
//}
This allows displaying the viewfield view(s) on the same node from which it derives its data.
The viewfield views argument is also stored, for instance [author-uid].
No errors so far.
Am I overlooking something? or is this a quick fix to the problem?