xapp:browse pagesize bug ?

It seems like the xapp:browse tag could have a bug where the first page size is always equal to or less than 10 elements.
When setting the pagesize to a number less than 10 the first browse page display the correct number of elements. When setting the page size to a number larger then 10 the first browse page always displays only 10 elements.
If used in conjunction with a xapp:browsenavigation tag (back and forward), going to the second page will display the correct number of elements specified in the pagesize. When going back to the first page again the correct number of elements are display this time.
It seems to be a display problem where only 10 elements are rendered but the iteration of elements occurs the number of times specified in the pagesize attribute.

I found this out by trying the the solution that was posted for “select with ino:id as value” that uses the xapp:browse tag to populate the select box.
This method seemed to work fine when there were 10 or less items to be placed in the select box. Even though the pagesize was specified to be 1000, only 10 items would show up.



–joeycz


X-Application Version: 4.1.1
Tamino Version : 4.1.1
Platform : Win2k
WebContainer : Tamocat 4.1.1
JDK Version : 1.4.1

[This message was edited by Christian Freytag on 24 Apr 2003 at 08:15.]

Hello Joey,

could you post the JSPs where you detect the error?

To create the document set that is iterated by the browse tag, are you using
- a directcommand tag of type xquery / query or
- an action tag of type search

If it’s the second version, please post the JSP sending the search request also and I will analyze the problem.

Many thanks.

Bye,
Christian.

Hi Christian,
I was mistaking about the xapp:browse tag having an error when used to browse documents in conjunction with the xapp:browsenavigation tags. Although the error that I was experienceing before i switched to using the new tag came from the following example posted to this forum previously.


<xapp:setvar name=“textVal” scope=“session”>
for $x in input()/Property/Address/State return x<BR></xapp:setvar><BR><BR><!process query--><BR><xapp:directcommand type="xquery" collection="{xappCollection$}" document=“select” arg="{textVal}"/>




<xapp:browse pagesize=“1000” document=“select” >
<option value="<xapp:display select="$ID"/>"><xapp:display select="/State"/>
</xapp:browse>



even though the page size is set to 1000 my select box always contains only 10 elements.

i have attached an old archive of my web application as a tar gzip file. My most recent versions are using the new xapp:select tag that circumvents this problem. Test data is located in apps/schemas/instances. The files in question are apps/capabilityType/create.jsp and modify.jsp
I have removed the jar files to minimize the file size. The jar files are the default files that the XApplication generator genrates.

–joeycz
apps-without_new_xapp_2D85C.tgz (317 KB)

Hello Joey,

thank you for your response. In this way I could reproduce the problem. It is a bug of X-Application.

I will try to fix it, but I could also find a workaround: Instead of using the pagesize attribute of the xapp:browse tag, you can set the :pagesize variable which is responsible for the intial size of a cursor.

For the example you posted, the workaraound would look like this:

<!-- Define the query-->
<xapp:setvar name="textVal" scope="session">
  for $x in input()/Property/Address/State return $x
</xapp:setvar>

<!-- Process query-->
<xapp:setvar name=":pagesize" value="1000" />
<xapp:directcommand type="xquery" collection="${xappCollection$}" document="select" arg="${textVal$}"/>

<!-- Fill HTML select tag -->
<select name="varSelection">
  <option value=""></option>
  <xapp:browse document="select" >
    <option value="<xapp:display select="$ID"/>"><xapp:display select="/State"/></option>
  </xapp:browse>
</select>



Hope, this helps you when you browse document sets you created via xapp:directcommand.

Whoever needs the fix for this bug, because the workaround is not applicable: Please sent a post to this topic and I will force my work on this problem.

Bye,
Christian.