We are pleased to announce the immediate availability of Servoy 6.0 beta 1.
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.
To update a Servoy eclipse open Check for updates via help menu.
@Kahuna
Well here’s my first:
returning data from an authenticator module method called by a login module fails (null returned) whereas in 5.2.7 it worked fine. (So wait for this to be fixed…)
Thomas Parry: @Kahuna
Well here’s my first:
returning data from an authenticator module method called by a login module fails (null returned) whereas in 5.2.7 it worked fine. (So wait for this to be fixed…)
Well that is a bug and not an expected change of behavior going from 5.1.x to 6.0. Which is what Ian was asking for.
@kahuna, I think for now you need to scan all the [enh] tagged issues in the release notes of 6.0a1 up to this version and see if that affects your code.
Thanks for the Heads up on the bugs Guys. I think we’ll leave it alone for another beta or two.
Hope Servoy manage to get a How To … up on the WIKI soon for the roll-over, I think they did something similar for 4 to 5 if my memory serves me well, but certainly Bob Cusik did a great job of explaining the differences and how to handle 5 in his Servoy Camp slides.
Thomas Parry:
returning data from an authenticator module method called by a login module fails (null returned) whereas in 5.2.7 it worked fine. (So wait for this to be fixed…)
Tom,
This is not an issue with the authenticator, but with serialization of the resulting object.
It works fine with returning a simple value, but I did see an error with returning a data set.
What are you returning?
What does the stack trace in the logs say?
I think for now you need to scan all the [enh] tagged issues in the release notes of 6.0a1 up to this version and see if that affects your code.
No need for this, just read the Release Notes on the wiki: http://wiki.servoy.com/display/beta/New+in+this+release. It contains a complete overview of all things new and improved in Servoy 6 up to Servoy 6.0 A7 (B1 additions will be added today.)
The paragraph “Solution Development” starts of with a list of the behavior changes which you would need to review to see if they might impact your solution. Besides those, your solution should just work.
Now, additionally there are the new things that were introduced that you might want to start using, possibly replacing now deprecated API. The new items in the scripting API and also the list of items we deprecated are also listed in the Solution Development section of the release notes. (Note that deprecated doesn’t mean that it won’t work anymore, it just means that there is a better way to do things. Also note that in Servoy 6 warning markers are generated in Servoy Developer for JavaScript code that uses deprecated scripting API)
Thirdly we introduced much better designtime validation of the JavaScript code, which most likely results in loads of warnings. Note these are warnings, not errors, so your solution could work just fine. However, the new refactoring functionality and/or the improved JavaScript search, search for references and Call Hierargy all depend on the build/validation process in Servoy Developer being able to completely analyse your code. Many of the builder/validator warnings generated in Servoy Developer are indications that that process cannot resolve references to objects or properties of objects that you refer to in your code. Besides a possible bug in your code here and there, most of these warnings can be solved by properly annotating your methods with JSDoc that document that parameters and the returnType of the method.
The Script Editor section in the Release Notes on the wiki contains an extensive overview of the options you have in the JSDoc area.
Do not get scared by the shear number of warnings you might have in your solution when you first open it up in Servoy Developer in Servoy 6: documenting 1 method with JSDoc might solve many warnings throughout your code.
If you run into anything that doesn’t work like it worked in Servoy 6 and it’s not listed under the behavior changes in the release notes, please let us know, so we can either fix it, or update the release notes accordingly
I reckon we will wait for the next beta before venturing into 6 but for the first time in a while I’m getting excited about Servoy again! Looking forward to trying out some of these new tools.
Thanks fro the feedback - we’ll keep an eye on the Wiki a bit more closely.
Thomas Parry:
returning data from an authenticator module method called by a login module fails (null returned) whereas in 5.2.7 it worked fine. (So wait for this to be fixed…)
Tom,
This is not an issue with the authenticator, but with serialization of the resulting object.
It works fine with returning a simple value, but I did see an error with returning a data set.
What are you returning?
What does the stack trace in the logs say?
Rob
Hi Rob,
I see the same issue in the current 5.2.7i1 build. I also return a dataset and get null. In the server log, I see this
java.lang.NoSuchMethodError: com.servoy.j2db.server.headlessclient.HeadlessClientFactoryInternal.createAuthenticator(Ljava/lang/String;Ljava/lang/String;[Ljava/lang/Object;)Lcom/servoy/j2db/ISessionClient;
at com.servoy.j2db.server.Zo.run(Zo.java:26)
at java.lang.Thread.run(Unknown Source)
patrick:
java.lang.NoSuchMethodError: com.servoy.j2db.server.headlessclient.HeadlessClientFactoryInternal.createAuthenticator(Ljava/lang/String;Ljava/lang/String;[Ljava/lang/Object;)Lcom/servoy/j2db/ISessionClient;
at com.servoy.j2db.server.Zo.run(Zo.java:26)
at java.lang.Thread.run(Unknown Source)
Patrick,
You need to get new server jars when running from svn trunk, this method has been removed.
@Rob,
Servoy 6.0 beta 1 installed from scratch.
A login module method based on the example for the enhanced security (onDataChange user name) calls an authenticator method (in another module) with the name of the user in order to do:
var dataset = databaseManager.getDataSetByQuery(<server name>, query, args, 10)
which then returns the dataset (which comprises 4 columns: staff_id (integer) user_name (string) name_last (string) and name_first(string)).
The authenticator method does its job properly then returns the dataset to the login module calling method where it is assigned to a form var. The contents are null.
This works in 5.2.7 but not in 6.0 b1
The log file has an error indicating some zip file cannot be opened and then the json error. I have attached the log file.
@Rob
I shall look forward to testing it in 6. but I would hope that this could be back ported to 5.2.x since I had issues with getting a byte array back from the authenticator (json serialisation).
What is the correct way to document in Servoy the properties of custom JavaScript “types” using JSDoc?
For example, in a form named “customTypes” we have something similar to:
/**
* Custom type for form parameters
*
* @constructor
* @param {String} _name
* @param {Object} [_value]
*/
function FormParam(_name, _value)
{
/** @type {String} */
this.name = _name;
/** @type {Object} */
this.value = _value;
}
/**
* Custom complex type which uses another custom type as a property
*
* @constructor
* @param {String} _formName
*/
function ComplexType(_formName)
{
/** @type {String} */
this.formName = _formName;
/** @type {forms.customTypes.FormParam} */
this.formParam = new forms.customTypes.FormParam('SPECIAL_PARAM_NAME');
}
Now when we use the custom ComplexType, the code completion works correctly but only for its own properties. If we try to access some of the properties of its formParam property, we get a warning that the property is not defined:
function doSomething()
{
//create a custom type - note that adding the @type tag to explicitly specify the custom type does not help in resolving the described issue
/** @type {forms.customTypes.ComplexType} */
var _complexType = new forms.customTypes.ComplexType('someFormName');
//here the "value" property of the formParam is "unknown" - the warning which we get is: "The property value is undefined in _complextType.formParam"
_complextType.formParam.value = {foo: 123};
}
Is the above usage supported by Servoy? Are we missing something in the properties documentation for the custom types? When we inspect the “formParam” property of the _complexType variable in the example above, the tooltip in Servoy is something like:
formParam Type
{forms.customTypes.FormParam} *
Note the trailing * at the end of the tooltip text - is this an indication of incorrect parsing of the @type JSDoc tag when the custom property is defined or are we using it incorrectly?
do: this.formParam = new FormParam(‘SPECIAL_PARAM_NAME’); (instead of the package before it)
in your script.
Currently it is not supported that if you are in a js file A and you reference something in B that everything in B also get resolved (so things from a js file C)
This is currently not possible because that would make everything very slow (because constantly everything needs to be resolved not to mention recursion B reference C and C references B)
