[ic] Having multiple [more] lists on one page

[Mike Heins]

Quoting Ethan Rowe (ethan at endpoint.com):
> Jure Kodzoman wrote:
> 
> >Hy list,
> >
> >I have a page on which I would like to have more than one [more] list.
> >
> >When i click on ie. link for the second page, it sends me to the
> >second page of another more list, and messes up results.
> >
> >I have tried setting prefixes on both queries, and in their
> >[more-list] respectively.
> >That didn't seem to help.
> >
> >Since Interchange's reaction to this is somewhat unusual, I wonder is
> >this even possible to achieve?
> >
> >Thank you for response,
> >
> >Jure Kodzoman
> > 
> >
> I may be mistaken, but I've looked into this area of Interchange fairly 
> extensively, and I think it's pretty difficult to get around this 
> limitation.

It just has never been put into the code. Part of the reason is
that the code is rather complicated. (Rather complicated is a
euphemism for "hacked-together monstrosity".)

> 
> The more-list logic is handled by the system's "scan" actionmap (the 
> function for which is defined in Vend::Page::do_scan() at 
> <IC_ROOT>/lib/Vend/Page.pm).  The "MM=<a_bunch_of_chars>:1:10:11:1" (for 
> example) that you see in the URL following "scan/" provides the cache 
> key telling the server which cached results file to use, and the various 
> numbers tell it the start and end records to display within the 
> particular looping region, as well as number of results per page.  The 
> scan engine itself simply pulls the contents of the cache file into 
> memory and sets a flag indicating that a more-list is in progress.
> 
> Unless I'm mistaken, the first looping tag (be it query, loop, search, 
> etc.) used for which more lists are activated will claim the current 
> more list.

No. The link that is clicked controls, so if you have two or more lists
all loops will use the results from the clicked loop.

> I'm not certain about this, but that's my recollection.  It 
> may be cleverer than this, and instead compare the cache key to the 
> cache key appropriate for the current loop tag and assume the more-list 
> doesn't match up if the keys don't match.  I don't remember seeing this 
> in the code when I looked, but it was a while ago.
> 
> In any case, the entire URL is focused on the one more-list in progress, 
> meaning that any other that may have been in progress cannot be any longer.
> 
> You may be able to do something tricky by storing the scan URLs for each 
> list in the user's session and potentially use the [update] tag between 
> each tag requiring more-list support.  The [update] tag lets you 
> basically call the process, scan, or search actions again, meaning you 
> might be able to get it to remember the current scan position for each 
> list and force each one to resume at its last position.  I've given this 
> only a little thought and this might be awful advice.  But it strikes me 
> as a possibility.

Actually you could get around it pretty easy with a couple of minor
hacks to the iterate_*_list routines in Interpolate.pm. I just have never
seen a real need for multiple more lists on a page, and I didn't ever take
it into account when doing the code.

-- 
Mike Heins
Perusion -- Expert Interchange Consulting    http://www.perusion.com/
phone +1.765.647.1295  tollfree 800-949-1889 <mike at perusion.com>

Software axiom: Lack of speed kills.