Servoy 6.0 alpha 5

Release notes for Servoy betas

Re: Servoy 6.0 alpha 5

Postby jbader » Fri Mar 11, 2011 1:06 am

jcompagner wrote:
jbader wrote:
Code: Select all
var myNumber = 1;
myNumber.toFixed(1);




That example is what i gave to give you a piece of code why i think instanceof should work on that..
Because you can call all methods of that Number type you check for on it!
So purely looking at myNumber from a higher point of view it is a Number ...
It doesn't really matter how you declared it..

jbader wrote:PS you do realize how hard this makes explicit type checking and assertions in unit testing right?


No not really can you give me an example why it makes it hard?

But i tested some more and came to a conclusion that some pieces of javascript are just weird:

Code: Select all
var x = true
var y = true
alert(x == y); // TRUE

var x = new Boolean(true)
var y = true
alert(x == y); // TRUE

var x = true
var y = new Boolean(true)
alert(x == y); // TRUE

var x = new Boolean(true)
var y = new Boolean(true)
alert(x == y); // FALSE?????


that is just weird...


I see your point about number vs Number in the example we both gave. What is the point afterall in having the primitive at all if you can use the Number object's properties and methods on the fly without an exception being thrown. I certainly would agree that makes even having a primitive fairly useless. But the fact is that it is there and that is just how it works.

Regarding an example of why it makes explicit type checking dificult consider...


Code: Select all
/**
* Do something.
*
* @param {number} n A number primitive.
*
*/
function doSomething(n) {
   // Explicit type checking
   if(typeof(n) !== 'number') {
      throw new TypeError('N must be of type number.');
   }
   else {
      // Turn off the city's powergrid.
   }
}


In the above example if n were defined as follows in scripting...

Code: Select all
var n = 10;


Then the result of typeof above would be 'number' and the city's powergrid would be turned off.

If however it were defined as follows (also in scripting)...

Code: Select all
var n = new Number(10);


Then the result of typeof above would be 'object' and the city's powergrid would not be turned off.

Now if the parameter n were passed into the function from Servoy's Java code/not defined in scripting it would in fact be a Number object, but would also pass the typeof check(!) b/c from what I can tell you have somehow made n both Number and number.

So you might be thinking well sure, but who cares at the end of the day it's the number 10...and yeah, you are right, but the fact is I can't explicitly check it and determine what it really is.

Finally regarding all of the other examples the trouble with those are that you are checking falsy and truthy values, which you should never do in JS unless you mean to. The general rule is to ALWAYS use === unless you are purposely checking all falsy or truthy (or so says Crockford). In JS truthy and falsy values are strange indeed. Change your '==' to '===' and everything will change.
jbader
 
Posts: 520
Joined: Sun Sep 18, 2005 4:24 am
Location: Miami, FL

Re: Servoy 6.0 alpha 5

Postby jcompagner » Fri Mar 11, 2011 1:22 am

jbader wrote:In JS truthy and falsy values are strange indeed. Change your '==' to '===' and everything will change.


No then the values are also of the truth

i see === as what in java == is (ok not completely the same but close)
and i see == what in java for the most part object.equals() is..
And that is what you want...
In java on objects we almost never use == (so === in js) but almost always .equals() (so == in js)

Because normally you always want to have content equals not object same instance equals..
But a real content equals you don't really have in js i believe.

But in java you have this:

String str1 = new String("jeff");
String str2 = new String("jeff");

str1.equals(str2) (== true and that is what most people expect..)
Johan Compagner
Servoy
User avatar
jcompagner
 
Posts: 8828
Joined: Tue May 27, 2003 7:26 pm
Location: The Internet

Re: Servoy 6.0 alpha 5

Postby jbader » Fri Mar 11, 2011 5:51 am

jcompagner wrote:
jbader wrote:In JS truthy and falsy values are strange indeed. Change your '==' to '===' and everything will change.


No then the values are also of the truth

i see === as what in java == is (ok not completely the same but close)
and i see == what in java for the most part object.equals() is..
And that is what you want...
In java on objects we almost never use == (so === in js) but almost always .equals() (so == in js)

Because normally you always want to have content equals not object same instance equals..
But a real content equals you don't really have in js i believe.

But in java you have this:

String str1 = new String("jeff");
String str2 = new String("jeff");

str1.equals(str2) (== true and that is what most people expect..)


I think that is not a great comparison when in JavaScript you can do things like...

Code: Select all
js> var s = '1';
js> var n = 1;
js> s == n
true
js>


.equals in Java requires that the Object you are comparing to be of the same type as the object from which you are calling the equals method.

Anyhow I think there would be a lot of value in not deviating from JavaScript's standard too much (recently noticed that Paul made a similar comment on standards here: http://forum.servoy.com/viewtopic.php?f=13&t=15704&p=84444&hilit=constants#p84481), particularly if new features are being introduced which seemingly do some type checking in the editor. If the type checking does not conform to the JavaScript standard (or any known JavaScript standard) that will be quite confusing (especially when the mods to Rhino are unpublished)!

In my opinion the following should show a warning in the editor...

Code: Select all
/**
* Do something.
*
* @returns {number}
*/
function doSomething() {
   return new Number(10);
}



6 really looks very neat though, and it's obvious a lot of great work has been done.

Thanks
jbader
 
Posts: 520
Joined: Sun Sep 18, 2005 4:24 am
Location: Miami, FL

Re: Servoy 6.0 alpha 5

Postby rossent » Fri Mar 11, 2011 8:57 am

Using directly the constructors new Number(x), new String(x) and new especially new Boolean(x) is very seldom needed. JavaScript does that for you silently when necessary.

Beware of this classical case explaining the differences between the primitives and objects:

Code: Select all
function someMethod()
{
   var x = false;
   var test1 = x ? 'What?!' : 'Duh!';
   application.output('Test 1: ' + test1);
   
   var y = new Boolean(false);
   var test2 = y ? 'What?!' : 'Duh!';
   application.output('Test 2: ' + test2);
   
   var n1 = 0;
   var test3 = n1 ? 'What?!' : 'Duh!';
   application.output('Test 3: ' + test3);
   
   var n2 = new Number(0);
   var test4 = n2 ? 'What?!' : 'Duh!';
   application.output('Test 4: ' + test4);   
}


Using new Boolean(x) is a big no-no! And I would argue that you should never use new Number() either.

On a separate note, I think that when it comes to 3 instanceof Number Servoy should throw an exception since this is the standard (if someone needs that to evaluate to true, they will have to use the Object() function like Object(3) instanceof Number)
Rossen Totev
Argos Software
rossent
 
Posts: 288
Joined: Wed Dec 31, 2008 2:03 pm

Re: Servoy 6.0 alpha 5

Postby rossent » Fri Mar 11, 2011 9:01 am

One more case where the code inspection is not working correctly:

Code: Select all
/**
* @return {Boolean}
* @properties={typeid:24,uuid:"8F038E5F-54EE-4637-B383-3A4FF02DF108"}
*/
function firstMethod()
{
   var x = 10;
   var y = 20;
   if(x > 1)
   {
      //this generates the warning:
      //"Function firstMethod declares Boolean as type but returns Number"!
      return (y > 5);
   }
   //this then generates the warning:
   //"Return statement returns Boolean which is inconsistent with the previous return Number"
   return false;
}
Rossen Totev
Argos Software
rossent
 
Posts: 288
Joined: Wed Dec 31, 2008 2:03 pm

Re: Servoy 6.0 alpha 5

Postby rossent » Fri Mar 11, 2011 1:53 pm

Should we be able to remove at runtime from the solutionModel forms which have been created at design time?

For example:
Code: Select all
var _removed = solutionModel.removeForm('someFormCreatedInServoyDeveloper');


Currently, this is possible and I can think of a scenario where it might be used - for example, at runtime depending on user license, remove from the application certain functionality. The problem is that such removal is a really drastic measure and any code which uses things like:

Code: Select all
forms.someFromCreatedInServoyDeveloper.doSomething();


will get exceptions similar to "cannot call doSomething of undefined".

Can the solutionModel.removeForm be modified to either not remove forms created at design time with Servoy Developer (simply return false) OR add an optional second argument like solutionModel.removeForm(formName, [removeOnlyRuntimeForms]) which controls whether design-time forms can be removed or not (by default, removeOnlyRuntimeForms will be false so the current behavior is not changed)? I personally prefer the second option since it provides more functionality.
Rossen Totev
Argos Software
rossent
 
Posts: 288
Joined: Wed Dec 31, 2008 2:03 pm

Re: Servoy 6.0 alpha 5

Postby Thomas Parry » Fri Mar 11, 2011 4:31 pm

So what have I missed this time?
I exported a solution from Servoy 5.2.6 and attempted to import in 6a5. I get the message to enter the password because it is protected solution. Which it is not.
I use the developer to do the import.
The 6a5 is a brand new install, repository is brand new (the Postgres is the one bundled with Servoy).
Using Win Xp Pro Sp3.
Tom Parry
Prospect IT
Java/C++/Servoy/Jasper Reports/Simulation/Service Applications
http://www.prospect-saas.biz
Thomas Parry
 
Posts: 498
Joined: Thu Jan 10, 2008 8:48 pm
Location: Ottawa, Canada

Re: Servoy 6.0 alpha 5

Postby rossent » Fri Mar 11, 2011 6:25 pm

JSMethod has the property showInMenu, however the create method dialog does not have the option anymore to set that property.
Is this deprecated now? Can we still use it?
Rossen Totev
Argos Software
rossent
 
Posts: 288
Joined: Wed Dec 31, 2008 2:03 pm

Issue with tab panels on web client

Postby rossent » Sun Mar 13, 2011 2:12 pm

Hi all,

We are experiencing an issue with tab panels running in the web client. Basically we add tabs to the tab panels dynamically at run-time. However in the web client you cannot switch between the tabs - clicking on any tab different than the currently active one results in the indicator showing up "Loading..." and nothing else happens. Also when tabs are removed from the tab panel, removing the last one results in an "Internal Server" error page displayed. The default Servoy navigators on such dynamically added tabs also do not work in the web client (the same "Loading.." indicator and nothing else happens) if you click the next/previous buttons. However entering a record index in the entry field and pressing Enter does navigate correctly. It seems as if there is an issue with the Ajax calls or something like that.

More info: when we add the tabs, we provide all arguments to the addTab method and the tabs are added without any problems. The issue is present only when running in the web client - the smart client works fine. This appears to be an issue introduced in a5 since a4 worked correctly.

Any assistance on this is greatly appreciated!
Rossen Totev
Argos Software
rossent
 
Posts: 288
Joined: Wed Dec 31, 2008 2:03 pm

Re: Issue with tab panels on web client

Postby rossent » Sun Mar 13, 2011 2:36 pm

rossent wrote:...We are experiencing an issue with tab panels running in the web client...


Turns out the issue applies even if the tabs are added statically at design-time. Renders the web client unusable for us.

Submitted case 364621 along with a sample solution demonstrating the issue. In my opinion this should be escalated with highest priority and hopefully fixed with the next release.
Rossen Totev
Argos Software
rossent
 
Posts: 288
Joined: Wed Dec 31, 2008 2:03 pm

Re: Servoy 6.0 alpha 5

Postby jcompagner » Mon Mar 14, 2011 10:04 pm

jbader wrote:In the above example if n were defined as follows in scripting...

Code: Select all
var n = 10;


Then the result of typeof above would be 'number' and the city's powergrid would be turned off.

If however it were defined as follows (also in scripting)...

Code: Select all
var n = new Number(10);


Then the result of typeof above would be 'object' and the city's powergrid would not be turned off.

Now if the parameter n were passed into the function from Servoy's Java code/not defined in scripting it would in fact be a Number object, but would also pass the typeof check(!) b/c from what I can tell you have somehow made n both Number and number.


the thing that will be passed in (as an argument or foundset/reord.xxxx) will be seen as a "primitive" object in rhino
so typeof(record.numvalue) will always be 'number' (and stringvalue 'string' and so on)

so typeof is not different in anyway you expect
Its only that currently instanceof will also work, because of the patch, and in my eyes more logical to people, because from a high level view it is a Number.
(if it walks like a duck, quacks like a duck, looks like a duck, it must be a duck)
Johan Compagner
Servoy
User avatar
jcompagner
 
Posts: 8828
Joined: Tue May 27, 2003 7:26 pm
Location: The Internet

Re: Servoy 6.0 alpha 5

Postby jcompagner » Mon Mar 14, 2011 10:18 pm

jbader wrote:In my opinion the following should show a warning in the editor...

Code: Select all
/**
* Do something.
*
* @returns {number}
*/
function doSomething() {
   return new Number(10);
}




Don't think that will happen, currently number is just an alias for the Number type.

And the Parser/TypeInferencer doesn't currently have any differences between them. To fix we will have to introduce some very special support for "primitives" or duplicate Number type as number
problem is that purely from a usage point of view there is not much difference they are the same

and if for example they have a "var x" that is of type Number somehow
and you want to give that to a function that has as param {number}
then i guess to get the warning away you have to do

myfunction(parseInt(x)) ?

thats ugly and doesn't really bring you much.
and in my eyes only confuses people.
Johan Compagner
Servoy
User avatar
jcompagner
 
Posts: 8828
Joined: Tue May 27, 2003 7:26 pm
Location: The Internet

Re: Servoy 6.0 alpha 5

Postby jcompagner » Mon Mar 14, 2011 10:21 pm

rossent wrote:
On a separate note, I think that when it comes to 3 instanceof Number Servoy should throw an exception since this is the standard (if someone needs that to evaluate to true, they will have to use the Object() function like Object(3) instanceof Number)


throw an exception? That is not the standard, browsers just return false,
Johan Compagner
Servoy
User avatar
jcompagner
 
Posts: 8828
Joined: Tue May 27, 2003 7:26 pm
Location: The Internet

Re: Servoy 6.0 alpha 5

Postby jcompagner » Mon Mar 14, 2011 10:23 pm

rossent wrote:One more case where the code inspection is not working correctly:

Code: Select all
/**
* @return {Boolean}
* @properties={typeid:24,uuid:"8F038E5F-54EE-4637-B383-3A4FF02DF108"}
*/
function firstMethod()
{
   var x = 10;
   var y = 20;
   if(x > 1)
   {
      //this generates the warning:
      //"Function firstMethod declares Boolean as type but returns Number"!
      return (y > 5);
   }
   //this then generates the warning:
   //"Return statement returns Boolean which is inconsistent with the previous return Number"
   return false;
}


this is fixed for alpha 6

P.S. sorry for the late replies, i was way busy with the out of mem problems that took quite a while to completely figure out and fix (even half a saturday)
Johan Compagner
Servoy
User avatar
jcompagner
 
Posts: 8828
Joined: Tue May 27, 2003 7:26 pm
Location: The Internet

Re: Servoy 6.0 alpha 5

Postby jcompagner » Mon Mar 14, 2011 10:28 pm

rossent wrote:Should we be able to remove at runtime from the solutionModel forms which have been created at design time?


when i creates solutionModel, i didn't have that method added at the first place, but i got all kind of things like, i want to be able to do that.
My question was, why would you do that?? (i sort of still have that question...)

But you could add a case to add that boolean (yes default has to be to remove anything)
Johan Compagner
Servoy
User avatar
jcompagner
 
Posts: 8828
Joined: Tue May 27, 2003 7:26 pm
Location: The Internet

PreviousNext

Return to Latest Releases

Who is online

Users browsing this forum: No registered users and 15 guests