[ic] Having multiple [more] lists on one page
Mike Heins
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
> 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.
More information about the interchange-users
mailing list