[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