Hi Sideview,
I have a SavedSearch that I then PostProcess (for deduping values). I then pass these values to the tabs module. Using tabs it seems to ignore the postprocess deduping and lists the values multiple times in the tabs. If i switch from tabs module to checkboxes module it uses the postprocessed deduped values and only creates one checkbox per value.
Is that expected behavior ATM for the tabs module?
Thanks
J
Ah! No. It's a bug in Tabs. I'll get it fixed in next maintenance release, and there's an easy workaround detailed below.
First, some background:
The expected behavior of Tabs with respect to postprocess, when configured to render one or more dynamic tabs, is as follows:
1) any upstream postprocess search, (eg those implemented with a PostProcess module), should be used automatically when the module gets search results to render its options (in this case its tabs).
2) when configured with <param name="postProcess">
, you can set your own postProcess string here in the module itself rather than having to insert an extra PostProcess module. This postProcess param will do $foo$ substitution on any $foo$ tokens you set therein.
3) If in your postProcess param, you want to pick up an existing postprocess search from an upstream PostProcess module, you can use the token $postProcess$ in your postProcess param
The problem with Tabs, is that #1 doesn't work. Note that #1 does actually work for the other "cousins" ie Pulldown, Checkboxes and Radio modules. It's just the Tabs module that suffers this problem.
This is easy to fix and I'll get it fixed in the next maintenance release. Thanks very much for bringing it to my attention!
WORKAROUND:
this workaround looks a little lame, but it'll work just fine and it'll continue working even after I make the fix in the next maintenance release. That is to put this param in the Tabs module:
<param name="postProcess">$postProcess$</param>
You're basically relying on #2 and #3 to do the job of #1.
Ah! No. It's a bug in Tabs. I'll get it fixed in next maintenance release, and there's an easy workaround detailed below.
First, some background:
The expected behavior of Tabs with respect to postprocess, when configured to render one or more dynamic tabs, is as follows:
1) any upstream postprocess search, (eg those implemented with a PostProcess module), should be used automatically when the module gets search results to render its options (in this case its tabs).
2) when configured with <param name="postProcess">
, you can set your own postProcess string here in the module itself rather than having to insert an extra PostProcess module. This postProcess param will do $foo$ substitution on any $foo$ tokens you set therein.
3) If in your postProcess param, you want to pick up an existing postprocess search from an upstream PostProcess module, you can use the token $postProcess$ in your postProcess param
The problem with Tabs, is that #1 doesn't work. Note that #1 does actually work for the other "cousins" ie Pulldown, Checkboxes and Radio modules. It's just the Tabs module that suffers this problem.
This is easy to fix and I'll get it fixed in the next maintenance release. Thanks very much for bringing it to my attention!
WORKAROUND:
this workaround looks a little lame, but it'll work just fine and it'll continue working even after I make the fix in the next maintenance release. That is to put this param in the Tabs module:
<param name="postProcess">$postProcess$</param>
You're basically relying on #2 and #3 to do the job of #1.
by the way the underlying bug is now fixed and it'll go out in the next release, probably numbered 2.6.4, probably releasing next week or maybe the week after.
Worked like a charm. Thanks again!