Page 1 of 1

Servoy 4.0 rc 1

PostPosted: Thu Jun 12, 2008 3:08 pm
by svroemisse
We are pleased to announce the immediate availability of Servoy 4.0 rc1

NOTE: this is PRE-RELEASE SOFTWARE, use with caution and make BACKUPS before you start

Make a backup of your current Servoy installation (directory and database) before installing.

If you find a bug or have a feature request, please file a case in our support system: http://crm.servoy.com/servoy-webclient/ ... oy_support

Since several file structure changes have been made, you should commit any outstanding changes and delete all solutions in your workspace before installing this version.

This version is available through the download page on the Servoy website (developer section). This version will also be available through auto update shortly.

Changes in Client
[fix] case 99940: right to left is not applied to the navigator and toolbars
[fix] case 138405: SSL use is not shown in smart client status bar when using the HTTP tunnel over HTTPS

Changes in Developer
[new] case 47296: removeTableFilterParam(...), based on name which is a new optional argument in addTableFilterParam(...)

[fix] case 123191: preferences panel for form designer as seen in old developer
[fix] case 132957: 3.5 solution releases and servoy 4.0 mismatch, made possible to create new releases from admin page when running as team server
[fix] case 138079: the background of forms in designer is always white, no matter what the style says. Also fixed background size/resize issue icw form inheritance
[fix] case 138431: creating multiple new records in a portal sometimes fails on null constraint
[fix] case 138738: IClock bean doesn't show in debug client
[fix] case 138879: building workspace sometimes takes a very long time
[fix] case 139140: problem marker generated when duplicate servers are found
[fix] case 139428: Sybase database creation feature changes uppercase username into lowercase

Known issues
- installer quits with error on machines running Java 1.5.0-b64
- text toolbar missing
- restart required after database creation (dialog will be shown in next release)

Previous release
http://forum.servoy.com/viewtopic.php?t=10550

One more know issue

PostPosted: Thu Jun 12, 2008 6:04 pm
by Andrei Costescu
You will probably notice that in web client, custom navigators appear to the right instead of left for solutions that have text orientation default.
This is a known issue that is solved in rc2 and appeared as a side effect of adding some more support for right-to-left orientation.

Creating global variables of type OBJECT

PostPosted: Thu Jun 19, 2008 1:26 am
by jbader
It would be nice to see "OBJECT" in the list of selectable types in the "new global variable" dialog. Currently if I select TEXT as the variable type, then try to define an object (using object literal notation), Servoy wraps the object in quotes. Additionally, if I create a new global variable of type object by hand, Servoy shows the variable as type TEXT (in the tooltip for example).

var foo = {name: "hello"}

should be type OBJECT

**I know that in the past I have used type MEDIA to store objects, and currently in RC1 I can set the default value of a new global variable of MEDIA to object literal notation without Servoy wrapping it in quotes, but again, it would be nice to see type OBJECT.

Thanks

NUMBER vs. INTEGER

PostPosted: Thu Jun 19, 2008 3:39 pm
by jbader
Also, another thing with the create new global variable dialog in RC1, I noticed that there is a NUMBER and an INTEGER type available, but in JS I thought that all "numbers" were mapped to doubles so I am unclear what the difference between INTEGER and NUMBER is for the definition of a global var.

1 and 1.0 are identical in JS no? If so, maybe NUMBER should stick around and INTEGER should go away. :?:

Thanks

Object Types and Integers vs. Numbers

PostPosted: Wed Jul 02, 2008 3:26 pm
by jbader
Any discussion or conclusions on either or the posts I put here. Re: Object types and integers vs numbers in the new var dialogs?

Thanks

Discussion

PostPosted: Wed Jul 02, 2008 3:49 pm
by Andrei Costescu
You can still use MEDIA. So when you want to define an object set it's type to MEDIA. If we were to add OBJECT too, then MEDIA and OBJECT would have the same meaning. What will happen then when you decide to edit that variable? Which type do we display as current? MEDIA or OBJECT? You cannot replace MEDIA type with OBJECT all together...

About the NUMBER - INTEGER thing: they are both there to be able to use the types of DB columns... might be helpful when you are using variables to store information taken from the DB or written to the DB, even if JS does not require it.

PostPosted: Wed Jul 02, 2008 4:01 pm
by Joas
Another reason that I can think of to have the separation between integers and numbers is that they usually have different default formats.

Integers

PostPosted: Wed Jul 02, 2008 4:24 pm
by jbader
Thanks for the reply.

The default format comment makes sense at the dataprovider level although I don't believe that JavaScript has "integers," so an integer variable type might not be best. It only has "doubles" so I guess what I am trying to figure out is what does "INTEGER" mean in Servoy 4? I think it means the exact same thing as "NUMBER" and that is a little confusing for me.

When would I use integer as opposed to number as a variable type?

http://www.crockford.com/javascript/survey.html

Thanks.

PostPosted: Wed Jul 02, 2008 4:35 pm
by patrick
The difference between numbers and integers might be important whenever such a global is used in a relation. I haven't tested, but I can imagine that this is a problem.

Numbers vs. Ints. contd.

PostPosted: Wed Jul 02, 2008 4:41 pm
by jbader
The difference between numbers and integers might be important whenever such a global is used in a relation. I haven't tested, but I can imagine that this is a problem.


True. Although currently there is no sanity checking on number vs integer types when they are created or edited. So I can create an integer with a value of 1.56 and a number with a value of 1 (which is really 1.0 in JS).

PostPosted: Wed Jul 02, 2008 5:25 pm
by jcompagner
if you create an integer with the value 10.10 (in scripting) then this will be a double.

then if you make this 10 again it will stay a double.

if you make a variable in js that has the value 10 it will be a integer. But if you change it then to 10.10 we will convert it to a double

?

PostPosted: Wed Jul 02, 2008 7:06 pm
by jbader
I am sorry but I don't understand completely.

application.output(10) yields 10.0 - a non-integer value - b/c there are no integers in JS.

If I create var foo = 10;

10 is really 10.0, it will never be 10.

Now if you are saying that behind the scenes Servoy is doing some casting to a Java Integer for all variables of type "Integer" then so be it, but within servoy methods, 10 is a double. So my question is, is there a technical difference in Servoy 4 between a variable type of "number" and a variable type of "integer?" If there is, what is it? If there is not, then why have both?

Again, thanks for all the replies!

PostPosted: Thu Jul 03, 2008 9:29 am
by jcompagner
it will be a integer in the servoy code
So if you have a global that you define as a integer
then if you store it in that global and show it or use it in a relation/find it will be an integer

Yes in javascript everything is a double if you work with it.

Thanks for the clarification

PostPosted: Thu Jul 03, 2008 4:15 pm
by jbader
Thanks Johan for clarifying.

What I understand now is that when I choose a data type for a variable what I need to be sure of is that when I assign a value to that variable either by way of scripting or initializing etc. I need to be sure that the value I provide WILL CAST to the corresponding Java data type. I don't necessarily need to be sure that the value is in itself that datatype natively in JS.

So for example, I could create a variable with the type of integer and assign it the value 1.56, b/c that will cast to 1, an integer. But if I assign the value "a" to a variable of type integer then my relationships or other Servoy features dependent on that variable being an integer will break. And in this case, since JS is dynamically typed, and the editor/interpreter has no way of alerting me that the value I am assigning to an integer variable is not actually an integer (or rather won't cast to an integer), I will not be warned. Correct?

I think this is probably an important clarification for all.

Again, thanks very much for all the replies on this thread.