[ic] Having multiple [more] lists on one page
mike at perusion.com
Sun Aug 14 13:25:54 EDT 2005
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
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.
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.
More information about the interchange-users