[ic] Having multiple [more] lists on one page
Ethan Rowe
ethan at endpoint.com
Sat Aug 13 20:39:08 EDT 2005
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.
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. 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.
I hope this helps.
- Ethan
--
Ethan Rowe
End Point Corporation
ethan at endpoint.com
More information about the interchange-users
mailing list