cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Dam <d....@hippo.nl>
Subject Re: cocoon 2.1.8 - RepeaterJXPathBinding, order of rows is inverted
Date Fri, 16 Jun 2006 19:03:55 GMT
Antonio,

thanks for the response.. I added the issue to Jira under COCOON-1864 
<http://issues.apache.org/jira/browse/COCOON-1864>.

regards,
Dennis Dam

Antonio Gallardo wrote:
> Hi Dennis,
>
> thanks for your contribution. Would you kindly add it to our issues 
> traking system [1]?
>
> Many thanks in advance,
>
> Best Regards,
>
> Antonio Gallardo
>
> [1] http://issues.apache.org/jira/browse/COCOON
>
> Dennis Dam escribió:
>> Hello all,
>>
>> I found a bug in the forms block of Cocoon 2.1.8 / 2.1.9. I found 
>> that putting a min-size / initial-size attribute on a repeater 
>> element in the CForms model, inverts the order of rows upon binding 
>> the form. So for example the input document looked like:
>>
>> <document>
>>  <row>a</row>
>>  <row>b</row>
>>  <row>c</row>
>>  <row>d</row>
>> </document>
>>
>> and my repeater model element's intial-size was set at 3. After 
>> transforming the forms template with the forms transformer, I see the 
>> following field instances (pseudocode):
>>
>> <field>c</field>
>> <field>b</field>
>> <field>a</field>
>> <field>d</field>
>>
>> So what happens? The JXPathbinding for the repeater inverts the order 
>> of the elements with index < initial-size! I traced this bug back to 
>> the org.apache.cocoon.forms.binding.RepeaterJXPathBinding class, 
>> where I found the following code snippet in the doLoad() method:
>>
>>            while (rowPointers.hasNext()) {
>>                // create a new row, take that as the frmModelSubContext
>>                Repeater.RepeaterRow thisRow;
>>                if (initialSize > 0) {
>>                    thisRow = repeater.getRow(--initialSize);
>>                } else {
>>                    thisRow = repeater.addRow();
>>                }
>>
>>
>> I changed this into:
>>
>>        int currentRow = 0;
>>        while (rowPointers.hasNext()) {
>>            // create a new row, take that as the frmModelSubContext
>>            Repeater.RepeaterRow thisRow;
>>            if (currentRow < initialSize) {
>>                thisRow = repeater.getRow(currentRow++);
>>            } else {
>>                thisRow = repeater.addRow();
>>            }
>>
>> and now the binding works correctly / like I want it to work :). I 
>> must note that I do NOT use an identity in my repeater binding 
>> declaration. But I think it would be logical that leaving out the 
>> identity element should result in preservation of the order the 
>> elements occur in the input document.
>>
>> Is there a reason for inverting the binding order of the "minimum set 
>> of rows"? If not, could someone fix this issue in 2.1.8 / 2.1.9?
>>
>> regards,
>> Dennis Dam
>>
>>
>>
>


Mime
View raw message