Project

General

Profile

Feature #264

getRecord() on foundsets is zero based

Added by Patrick Ruhsert almost 9 years ago. Updated almost 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
04/07/2011
Due date:
% Done:

0%

Estimated time:
Browser (if web client):

Description

the getRecord() method on a foundset seems to be Java style zero based. In one of my reports I do

$record.record_to_other_table.getRecord(1)

on a 1:1 relation and do not get a record. I get the one with

$record.record_to_other_table.getRecord(0)

From a Servoy perspective, this is confusing.

Associated revisions

Revision 487 (diff)
Added by Patrick Talbot almost 9 years ago

Added "oneBasedLoops" defaultReportParameters property: default to false: loops are 0 based, set to true: loops are 1 based (for foundset.getRecord() and dataset.getRow())
Fixes request case #264

Revision 488 (diff)
Added by Patrick Talbot almost 9 years ago

Added "oneBasedLoops" defaultReportParameters property: default to false: loops are 0 based, set to true: loops are 1 based (for foundset.getRecord() and dataset.getRow())
Fixes request case #264

Revision 489 (diff)
Added by Patrick Talbot almost 9 years ago

Added "oneBasedLoops" defaultReportParameters property: default to false: loops are 0 based, set to true: loops are 1 based (for foundset.getRecord() and dataset.getRow())
Fixes request case #264

Revision 490 (diff)
Added by Patrick Talbot almost 9 years ago

Added "oneBasedLoops" defaultReportParameters property: default to false: loops are 0 based, set to true: loops are 1 based (for foundset.getRecord() and dataset.getRow())
Fixes request case #264

History

#1

Updated by Patrick Talbot almost 9 years ago

  • Tracker changed from Defect to Feature

Hum. I get your point but I'm wondering if I can implement this now...
It will break existing reports who where relying on this method to be 0 based.

I should probably make a little poll out of this feature request to check what people are using, and make it very clear that a new version with this change would not be compatible.

I must say that I never had to use this.
I tend to put as much of the logic in the preparation of the objects in the context and only iterate in the template and perform small tests on values to tweak the display, avoiding as much as possible to put too much logic in it.

#2

Updated by Jeroen de Vries almost 9 years ago

I don't see how this is going to make our lives any easier. Zero/one based issues are everywhere, this is just another one.

#3

Updated by Patrick Ruhsert almost 9 years ago

Leave it as it is. I have already started with 0 based stuff also...

#4

Updated by Juan Antonio Santana Medina almost 9 years ago

Go ahead !!

+1

#5

Updated by Sem Tukenmez almost 9 years ago

We don't use this (for now), so it doesn't matter for me. But I have to agree with Jeroen.

#6

Updated by Victor Rojo Carballo almost 9 years ago

I donĀ“t use it in any report, so I'm safe if you change it.

#7

Updated by Patrick Talbot almost 9 years ago

  • Status changed from New to Closed

With v1.4.11 I have added a new defaultReportParameter: oneBasedLoop, if set to true, foundset.getRecord() and dataset.getRow() will be 1-based, set to false (the default) they will be 0-based (as it is now).

So the current behavior didn't change, but you will have a choice to set it to match Servoy's 1-based loops if you want to.

Simply add:

plugins.VelocityReport.addDefaultReportParameter( 'oneBasedLoop', true );

or
plugins.VelocityReport.setDefaultReportParameters( { 'oneBasedLoop': true, ... } );

somewhere in your scripts before using the plugin and you're all set!

I have updated the wiki with this information.

Also available in: Atom PDF