One thing I know for sure is that the Velocity plugin keeps my JavaScript objects intact and without the ‘noise’ the serializer plugin does.
Just saying.
jcarlos:
Sorry, but what does this exactly mean? Can you educate me on the topic?
Just that the VelocityReport have it’s own JSON serializer/deserializer. Especially useful with the Velocity web client to build killer web services.
And as Robert said, it produces pure JSON output.
ptalbot:
jcarlos:
Sorry, but what does this exactly mean? Can you educate me on the topic?Just that the VelocityReport have it’s own JSON serializer/deserializer. Especially useful with the Velocity web client to build killer web services.
And as Robert said, it produces pure JSON output.
What engine is it? I was assuming same one Rhino is using.
jcompagner:
the serializer is also used for other things like … column serializer
And it would be great if it could be used. We pulled this out of a solution once and coded with methods instead to catch any weird errors before they were saved down. Have avoided it since.
david:
What engine is it? I was assuming same one Rhino is using.
Nope, I use the one from JSON.org (right from the source): http://www.json.org/
(Which is why it’s also compatible with Servoy 5.x)
ptalbot:
david:
What engine is it? I was assuming same one Rhino is using.Nope, I use the one from JSON.org (right from the source): http://www.json.org/
(Which is why it’s also compatible with Servoy 5.x)
Errr…“the one from JSON.org”…don’t understand. Did you write your own encoder/decoder or use one of the [many] implementations listed?
The source implementation here: http://www.json.org/java/index.html
Hi,
There is new (and undesired) behaviour introduced in 6.1.1.
To avoid pagination on small lists we use forms that are longer than the tab-panel they are placed on (e.g. form=300px, tab-panel=80px). This will show a longer list of record before pagination is introduced. Since scrollable tables are not working properly (as reported above), we are now stuck without a solution or work-around. In the screen-shot you see an example of such a list. It will show pagination after the first row. In such a list there are typically no more that 3-4 rows.
Can this be re-introduced the way it was before 6.1.1 o we can have control of the way we want to display our lists?
[attachment=0]small_list.jpg[/attachment]
Wouter.
can you create a case (if possible with a sample) for this issue ?
wouter:
Hi,There is new (and undesired) behaviour introduced in 6.1.1.
To avoid pagination on small lists we use forms that are longer than the tab-panel they are placed on (e.g. form=300px, tab-panel=80px). This will show a longer list of record before pagination is introduced. Since scrollable tables are not working properly (as reported above), we are now stuck without a solution or work-around. In the screen-shot you see an example of such a list. It will show pagination after the first row. In such a list there are typically no more that 3-4 rows.
Can this be re-introduced the way it was before 6.1.1 o we can have control of the way we want to display our lists?
[attachment=0]small_list.jpg[/attachment]
Wouter.
Support issue opened for this. Jira
Hi All,
I am facing an issue in 6.1.1 which was not existing in 6.1 . I am using on render event . suppose a particular record is selected . But I am navigating to another record . When I am back to that form again then then both of the records are selected . How can this be possible ? . If again I am navigating through another record then three records are selected . The row selecting is not working properly .
// If the Record is selected.
if (Rec && event.isRecordSelected()) {
event.getRenderable().bgcolor = globals.graphics_row_bg_selected;
event.getRenderable().fgcolor = '#000000';
}
Please provide some feedback on this.
Thanks,
aksrot426
Another critical issue for us: In the web client, TYPEAHEAD fields which use value lists based on DB tables with real value column of type UUID and display value column of type TEXT are throwing the following error when the user tries to select a value from the list:
com.servoy.j2db.ApplicationException: Invalid input, Setting dataprovider with name ‘r_ab_popupmsg’, type ‘TEXT’ with value of wrong type ‘bbbbbbbbbb’
In this particular case, the TYPEAHEAD should have “translated” the ‘bbbbbbbb’ textual code displayed in the list to the actual UUID from the underlying record and set that UUID in the dataprovider. It looks like in 6.1.1 it simply tries to use the textual code in place of the UUID disregarding completely the fact that the display value and the real value (which needs to be returned to the dataprovider) are different.
Another issue related to TYPEAHEAD fields in the web client is when the used valuelist is configured to use a relation and the display and real values are using again different columns (a TEXT and an UUID) - in such cases the dropdown list does not show up at all.
Cases are created for these issues: SVY-2950 and SVY-2951
aksrot426:
I am facing an issue in 6.1.1 which was not existing in 6.1 . I am using on render event . suppose a particular record is selected . But I am navigating to another record . When I am back to that form again then then both of the records are selected . How can this be possible ? . If again I am navigating through another record then three records are selected . The row selecting is not working properly.
Please create a case for this one as well. Is it happening in web-client? A sample solution would be helpful.