You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Sandor Spruit <sa...@cs.uu.nl> on 2005/09/15 15:44:57 UTC

SOLVED (was: Re: Urgent: Paginator breaks ...)

This one was tricky. I had overlooked a crucial detail in the Paginator 
Howto, because the Transformer seemed to work as expected straight away.

Well it did but it broke, iff the current page number occurs as the last 
digit in my continuation ID (ouch!).

I've now slightly reorganized my sitemap as per the example in the Howto 
and everything seems to (really!) work now :)

Sandor

Sandor Spruit wrote:
> 
> Folks,
> 
> I'm seeing a strange StringIndexOutOfBoundsException right in the middle 
> of the Paginator:
> 
>     String index out of range: -1
> 
> I'm not capable (yet) of reproducing it, especially as we had a power 
> outage 30 mins ago, just as I'd nearly nailed it down :(
> 
> Maybe somebody has seen this before? The whole stacktrace is like 3 
> pages, relevant fragment refers (not-surprising) to String.substring:
> 
> Paginator.endElement (line 288)
>  > Paginator.addPaginateTags (line 360)
>   > Paginator.cleanUri (line 603)
>     > String.substring (line 1411)
>       > String.substring (line 1444)
> 
> It would also be a great help if somebody could explain what Paginator 
> does with the page numbering. It seems to fiddle with the URI to fold-in 
> references to other pages? It's kinda hard to see exactly what happens,
> as my URI contains dozends of numbers (a continuation ID) :(
> 
> Any suggestion *very* welcome, I would normally try to figure this out 
> myself but, well, I'm in a hurry and could do with a hint or two :)
> 
> cheers,
> Sandor
> 
> -----------------------------------------------------------------------
> Information and Computing Sciences, Utrecht University, the Netherlands
> 'Content and knowledge engineering' http://www.informationscience.nl/
> Personal coordinates: http://www.cs.uu.nl/people/sandor/
> "... unthinkable surprises, about to happen, but what they are -
>  it's not up to you, oh, it never really was."  (Bjork on Vespertine)
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
> 


-- 
-----------------------------------------------------------------------
Information and Computing Sciences, Utrecht University, the Netherlands
'Content and knowledge engineering' http://www.informationscience.nl/
Personal coordinates: http://www.cs.uu.nl/people/sandor/
"... unthinkable surprises, about to happen, but what they are -
  it's not up to you, oh, it never really was."  (Bjork on Vespertine)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: SOLVED

Posted by Jorg Heymans <jh...@domek.be>.
Sandor Spruit wrote:

> Right now, my biggest problem is that the Paginator seems to assume 
> request URIs of the pattern "page(#)" - where # is the page number. I
> had overlooked the "page(#)" pattern in the Howto.

maybe you could xsl the page() part into a request parameter path and
match this in your sitemap, sounds hacky though...

ie (from the example)
<images xmlns:page="http://apache.org/cocoon/paginate/1.0">
  <image />
  <image />
  <image />
  <page:page
     current="1"
     total="3"
     current-uri="/cocoon/samples/paginator/page(1)"
                                         ^^^^^^^^^^^^
                  transform this into ?page=1
     clean-uri="/cocoon/samples/paginator/page" />
</images>


> Paginator generates links to other pages by searching for the current
>  page number in the URI and replace the (#) with another number. My
> pipeline is triggered by a URI containing a continuation, so the
> paginator finds the current page number in the URI, as part of this
> large integer (sigh). The problems occur when the integer is the
> final digit in my continuation, because the Paginator tries to 
> replace (<number>) while the final ")" is obviously beyond the length
> of the String.

I suggest you log an issue in bugzilla together with your testcase,
maybe the Paginator just needs a bit more shielding as to what it should
search for.


Jorg


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: SOLVED

Posted by Sandor Spruit <sa...@cs.uu.nl>.
Jorg,

Thanks anyway for the suggestion. I've been away for a week, but it may 
still come in handy :)

Right now, my biggest problem is that the Paginator seems to assume 
request URIs of the pattern
"page(#)" - where # is the page number. I had overlooked the "page(#)" 
pattern in the Howto.

Paginator generates links to other pages by searching for the current 
page number in the URI and
replace the (#) with another number. My pipeline is triggered by a URI 
containing a continuation,
so the paginator finds the current page number in the URI, as part of 
this large integer (sigh). The
problems occur when the integer is the final digit in my continuation, 
because the Paginator tries to
replace (<number>) while the final ")" is obviously beyond the length of 
the String.

So, right now, my paginator is buried rather deep in my pipeline. I'll 
have to reshuffle the whole
thing and the associated flowscripts to correct this :(

Sandor

Jorg Heymans wrote:

>Sandor Spruit wrote:
>  
>
>>>It would also be a great help if somebody could explain what Paginator
>>>does with the page numbering. It seems to fiddle with the URI to
>>>fold-in references to other pages? It's kinda hard to see exactly what
>>>happens, as my URI contains dozends of numbers (a continuation ID) :(
>>>
>>>      
>>>
>
>Unrelated, but if you don't like to see the continuation ID in the URL
>you can pass it as a hidden param in the form and have a request param
>matcher for it, like
>
><map:match type="request-parameter" pattern="continuation-id">
>   <map:call continuation="{1}"/>
></map:match>
>
>and in the form template
>
><fi:continuation-id/>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Re: SOLVED

Posted by Jorg Heymans <jh...@domek.be>.
Sandor Spruit wrote:
>>
>> It would also be a great help if somebody could explain what Paginator
>> does with the page numbering. It seems to fiddle with the URI to
>> fold-in references to other pages? It's kinda hard to see exactly what
>> happens,
>> as my URI contains dozends of numbers (a continuation ID) :(
>>

Unrelated, but if you don't like to see the continuation ID in the URL
you can pass it as a hidden param in the form and have a request param
matcher for it, like

<map:match type="request-parameter" pattern="continuation-id">
   <map:call continuation="{1}"/>
</map:match>

and in the form template

<fi:continuation-id/>


Jorg


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org