Bug was apparently introduced by this patch:

http://svn.cocoondev.org/viewsvn/trunk/xreporter-cocoon/src/resources/common/stylesheets/html/output.xsl?view=diff&rev=618&root=xreporter&r1=618&r2=617&p1=trunk/xreporter-cocoon/src/resources/common/stylesheets/html/output.xsl&p2=/trunk/xreporter-cocoon/src/resources/common/stylesheets/html/output.xsl

I remembered that too, so I looked it up: http://lists.cocoondev.org/pipermail/xreporter/2004-May/001417.html

Looks like the chunkLength parameter should just be left off altogether, no?


> -----Original Message-----
> From: xreporter-bounces@lists.cocoondev.org
> [mailto:xreporter-bounces@lists.cocoondev.org] On Behalf Of
> Marc Portier
> Sent: Monday, May 02, 2005 11:53 PM
> To: webbased db reporting - general mailinglist
> Subject: Re: [xreporter] Possible problem in chunk navigation
>
>
> can you point us to that message?
> -marc=
>
> bpire.cs@clearstream.com wrote:
> >
> > This is also the change that I did. But I remember reading in
> > previous post of the mailing list the possibility to have the
> > chunk-size fixed in a parameter in the cocoon.xconf.
> >
> > Is it really the case? If yes, why isn't it used here?
> >
> > Bernard
> >

Hm, I see the chunkLength URL hacking as a useful feature.

I see the need for the action (cocoon sitemap config) to decide for a default chunklength, and providing that to the xreporter backend.

I think the latter should just send-back that info (verbatim) in the chunkinfo section (now it only communicates the actual size of the current chunk, which for the last chunk is always going to be smaller)

That way the stylesheet doesn't need the hardcoded chunksize, nor will it confuse the number-of-rows-in-current-chunk with the chunkLength.

Fixed by adding an extra parameter "chunk-length" that doesn't shrink.
And updated the stylesheet to use that in stead.

commit-fix: svn rev 642 @ http://svn.cocoondev.org/viewsvn?view=rev&rev=642&root=xreporter

Changing resolution to 'Applied'