view for the 3rd level of an inclusion+discussion
Philipp, if I ever stop appreciating the clarity of your written communication, please send me a graphic visualization of my stupidity.
Yes, the syntax should work. I should really only be constrained by the "max_depth" value which is currently hard-coded as 20 in lib/card/format.rb (it's basically just intended as a preventative measure against recursion). This means Wagn only goes 20 inclusions deep. Until then the pipes should work, so this is a bug.
If I were more disciplined and less rushed, I would write a spec for this, but I'm pretty slammed and this setup is kind of involved. So perhaps you will just test my hunch first. If that doesn't work I'll do the right thing and write the spec.
My hunch is this:
Change line 19 of mods/standard/sets/type/pointer.rb from
wrap_item process_inclusion(icard, args.clone), args
to
wrap_item process_inclusion(icard, args.deep_clone), args
If that works, I'll get that merged into master and develop.
Thanks, I appreciate your enthusiastic, humorous way of flattering me :)
Unfortunately, deep_clone in pointer.rb:19 doesn’t help.
I’ve noticed that this problem only occurs with search cards, more precisely after the first search card in
an item list.
In the example above: if A is a pointer card and B a search card, then A and B get the correct view but
all cards after B switch to link view.
This change in Card::Format#process_inclusion (lib/card/format.rb) appears to fix it.
sub = subformat tcard
- sub.inclusion_opts = opts[:items]
+ sub.inclusion_opts = opts[:items] ? opts[:items].clone : {}
+
For what it's worth, the main thing required to reproduce the issue is multiple searches in closed view. When you render a search in closed view, it renders each item as a link. That link was getting plopped into the args hash on the first item's rendering and not cleared for the second, at which point "view":"link" got set in the JSON slot variables that get passed to the server with each of the slot's AJAX requests.
Kind of an edge case, but well worth fixing!