We are pleased to announce the immediate availability of Servoy 6.1 beta 1 release.
This version is available through the download option on the Servoy website and auto-update.
Always make a backup of your current Servoy installation (directory and database) before installing/upgrading. (this version will do a repository update!)
To update Servoy Developer open Check for updates via help menu.
For a complete overview of the new feature in this release see our wiki
The issue’s fixed only in 6.1 or not yet released in other version are: Client Changes
[fix] SVY-1697 Aggregate values in a label using display Tags are showing wrong values.
[fix] SVY-1694 Javascript error in Internet Explorer 8
[fix] SVY-1410 subclass row selection (odd, even selected) on portal
[fix] SVY-1288 webclient: no modifierKeys in various ‘drag’ events (onDrag/onDrop/etc)
[fix] SVY-1183 Combobox focus prevents selection of correct record
[fix] SVY-1041 Webclient decimal point on numpad
[fix] SVY-1023 Overloaded function in custom beans/plugins raise warning in Servoy 6
[fix] SVY-1019 problem with fallback valuelist
[fix] SVY-994 WebClient Issue
[fix] SVY-943 Webclient: Row selection highlight not always being cleared.
[fix] SVY-939 The method solutionModel.newRelation creates JSRelation objects with names always in lowercase regardless the specified name in the constructor
[fix] SVY-688 Setting border properties using CSS
[fix] SVY-619 scrolling html field
[fix] SVY-518 rotation of image not working in webclient
[fix] SVY-455 rectangle borders on web
[fix] SVY-199 Selected record changes on databroadcast in a related foundset problem
Developer Changes
[fix] SVY-1705 Serclips reponding very slow when expanding form node containing large number of forms
[fix] SVY-1549 Hovering over a foundset during debug is slow and information displayed is not very useful
Installer Changes
[fix] SVY-1030 beans/plugins directories not created if the corresponding optional components are de-selected in the installer.
can multiple modules/solutions in the same workspace define scopes with the same name? Currently Servoy Developer allows that but only one of the scopes is accessible (the other one does not show in the Script Editor code completion; this becomes an issue if two different modules, perhaps even from different vendors, define custom scopes with the same name and then a solution references both modules)
can different scopes define methods with the same name? Currently the Create Method wizard does not allow that (it treats all methods under globals and other custom scopes as “global” and displays the message that a “global method with the same name already exists”; however, if I manually create the method everything is fine and works as expected)
It will be helpful if some guidelines, DOs and DON’Ts regarding the scopes is added to the 6.1 wiki
It appears, that if I define a foundset variable like
/** @type {JSFoundSet<db:/sample_db/test_data>} */
var fs = databaseManager.getFoundSet('sample_db','test_data');
fs.customEntityMethod(); //this shows a warning that the customEntityMethod is not defined for JSFoundSet<db:/sample_db/test_data>
any methods which have been added to the test_data table are not accessible. However if I use something like
var fs = forms.test_data_form.foundset; //test_data_form is based on the same datasource db:/sample_db/test_data>
fs.customEntityMethod(); //this works OK
Is this a bug or intended behavior? Are the custom entity method accessible only for the default foundset or for any foundset based on that datasource? What happens if in two modules are defined custom entity methods with the same name? It appears, that the entity methods are available only for the foundset but not for the records from that foundset - is this the designed behavior?
can multiple modules/solutions in the same workspace define scopes with the same name? Currently Servoy Developer allows that but only one of the scopes is accessible (the other one does not show in the Script Editor code completion; this becomes an issue if two different modules, perhaps even from different vendors, define custom scopes with the same name and then a solution references both modules)
We shouldn’t allow this, this complicates stuff. Only 1 name should be allowed. and people should just use good names to differentiate between them
Please create a case for this.
rossent:
can different scopes define methods with the same name? Currently the Create Method wizard does not allow that (it treats all methods under globals and other custom scopes as “global” and displays the message that a “global method with the same name already exists”; however, if I manually create the method everything is fine and works as expected)
Yes that should be possible just fine, scopes are complete separate objects/javascript scopes so they don’t collide at all.
Please do create a case.
var fs = databaseManager.getFoundSet('sample_db','test_data');
fs.customEntityMethod(); //this shows a warning that the customEntityMethod is not defined for JSFoundSet<db:/sample_db/test_data>
that should work (as you say you can call it just fine)
I think i know what the problem is that is that we have here a java type (JSFoundSet) and a javascript portion that is now mixed.
That is always a bit of a problem, we need to check this, can you create a case?
With the Rhino 1.7R3 now we have in Servoy the standard JavaScript JSON support (beware of the one-way date serialization!).
However, it appears that the Script Editor currently does not recognize it even though it works just fine. Can we have support for it?
Also, a very good thing to mention is that now the const keyword is supported and it is a true constant! That is just GREAT! It will be very helpful to add that to the 6.1 wiki.
rossent:
With the Rhino 1.7R3 now we have in Servoy the standard JavaScript JSON support (beware of the one-way date serialization!).
However, it appears that the Script Editor currently does not recognize it even though it works just fine. Can we have support for it?
Will look if we can add that as a type.
Please create a case so that we don’t forget it.
rossent:
Also, a very good thing to mention is that now the const keyword is supported and it is a true constant! That is just GREAT! It will be very helpful to add that to the 6.1 wiki.
not sure about this one, yes rhino does support it, yes the editor supports it, but i don’t think it is supported anywhere else, i don’t think its in a ecma spec, so i am not sure if we should promote it because it could bite us later on.
One of the key feature of JavaScript is (or was) loose typing. Servoy benefits from that, because scripting is fast but still the output/the deployed solution is Java (with all of its wonderful widgets, etc.)
(1) I have not moved to Servoy 6 because I don’t want to be restricted by the new JSDoc implementation. For example, I don’t want to be typing the data type while defining variables, etc. Is there a way to set this by default instead of suppressing the warnings inside the code with @SuppressWarnings JSDoc tag?
If this is not possible I can live with that – moving forward/new solutions – no really a problem.
(2) But I can’t really live with that for all old solutions. Is there a way to suppress the JSDoc Warnings per solution? I don’t want to suppress this (feature) entirely, only on certain old solutions. Could this be possible under the Projects menu?
Currently under Projects menu we have there the ‘Clean…’ feature. We can ‘Clean Projects Selected below’ and not all –if we choose so.
It would be nice if we could select the JSDoc Preference there as well. With the option to ‘Suppress the JSDoc Warning on selected solutions/projects.’ Is this (or something similar) built in Servoy 6.1 or should I request this feature (if possible)?
This new Servoy release is really impressive. The support for installing the Servoy Application Server on any Java server is excellent! CSS3 support is awesome!
jcarlos: (1) I have not moved to Servoy 6 because I don’t want to be restricted by the new JSDoc implementation. For example, I don’t want to be typing the data type while defining variables, etc. Is there a way to set this by default instead of suppressing the warnings inside the code with @SuppressWarnings JSDoc tag?
If this is not possible I can live with that – moving forward/new solutions – no really a problem.
(2) But I can’t really live with that for all old solutions. Is there a way to suppress the JSDoc Warnings per solution? I don’t want to suppress this (feature) entirely, only on certain old solutions. Could this be possible under the Projects menu?
The short answer is jsdocs helps you big time with code complete and code refactor.
Bottom line you can do without and to prevent many warnings you can disable these as well
And to add to that: you can configure all the warnings on a project to project basis already, by selecting the option at the top of the Preference page where you do all the settings, called “Configure Project Specific Settings”
I think you should realize that the whole JSDoc think is only something to help you out while working in Developer.
Also: this has nothing to do with the 6.1 release so don’t cross post.
