Servoy 6.0 alpha 4

Classic Servoy
1

We are pleased to announce the immediate availability of Servoy 6.0 alpha 4

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 6.x eclipse open “Check for updates” via help menu.

For all the highlights read the wiki first :!:

Changes
[enh] 357330 find/search on foundset using IN operator with array
[fix] 358140 title boxes in preference pane in servoy 6.0a2 are not big enough
[fix] 357742 move form to other solution
[fix] 359849 COMBOBOX does not support UUIDs as real value/keys in the valuelist

In the full installer:
[chg] Bundled latest Tomcat version (6.0.32)
[chg] Bundles latest Postgres version (9.0.3)
There will be more library updates in next release.

2

Regarding the change as described in the wiki:

Added support for displaying HTML contained in the titleText property of non-editable HTMLArea’s. Useful to show (multiple) href links in the UI. Same functionality was already available through Labels, but on Labels the entire label acts as click-able area (showing a HAND cursor), whereas when done with an HTMLArea only the links are click-able.

Can you provide an example of that. So far I have not been able to do this. The only way I can display any links is if the dataprovider which the HTML_AREA field is linked to contains the necessary HTML, but this is the old standard behavior (we have been using this since Servoy 4.1 and perhaps it was available even before that) Basically, nothing which is in the titleText property of the HTML_AREA fields shows up.

3

Hi Paul,

My compliments for including all the new features in the wiki !!
I know it is a lot of work !

Regards,

4

rossent:
Can you provide an example of that. So far I have not been able to do this.

It might be needed to enble displayTags on the element to process the titleText at all outside tableview

5

Hi all

Is there a specific Servoy 6 forum? I saw one a few days ago, but can’t find it now.

I notice that application.showFormInDialog() is now deprecated, but I can’t find any details on what replaces it. I’d be grateful to be pointed in the right direction for the appropriate documentation / forum, or to be told what to use instead…

Thanks. :)

Bevil

6

Hi Bevil

Here is a link for the new 6.0 stuff.

http://wiki.servoy.com/display/beta/New+in+this+release

The Window API released in 6.0 is what replaces showFormInDialog()

Good Luck,
Lach

7

Thunder:
Is there a specific Servoy 6 forum? I saw one a few days ago, but can’t find it now.

This one ?

8

Thats the one Robert, thank you.

9

Hi all,

In Servoy 6, when overwriting a method in a sub-form, a warning is produced: “Function <function_name> hides variable”.

Basically our case is like this:

base form declares a method which is meant to be an “abstract” method - sub-forms must overwrite and provide specific implementation
sub-form overwrites the method introduced in the base form

Is there a way to indicate to the JSDoc parser this scenario so we do not get the warnings mentioned above? Ideally, this should be done automatically by Servoy when we use the option “Overwrite Method” from the Solution Explorer.

A big portion of the warnings which we get when porting our code from 5.2.6 to 6 is related to such “overwrites” from base forms. Any help on this is much appreciated.

Thanks!

10

rossent: i am currently looking into this to not generate those warnings.

11

Hi all,

Given the function:

/**
 * @return {JSFoundset<db:/argos_user_data/ab_process_status>} foundset of the method queue
 * 
 * @properties={typeid:24,uuid:"CCDBAC3B-5E60-4A68-BF4D-A0385C9DEC8E"}
 */
function getMethodQueueFoundset()
{
    /** @type {JSFoundset<db:/argos_user_data/ab_process_status>} */
    var _fs = databaseManager.getFoundSet('argos_user_data','ab_process_status');

   //additional code...

    return _fs;
}

We are getting the following warning:

Function getMethodQueueFoundset declares JSFoundsetdb:/argos_user_data/ab_process_status as type but returns JSFoundset

Inside the function body, the code completion for the _fs typed foundset works as expected.

Why are we getting this warning? Are we missing something or is this an issue which needs to be resolved by Servoy? Has someone else experienced similar issues?

Thanks for your help?

12

jcompagner:
rossent: i am currently looking into this to not generate those warnings.

Johan,

Thanks for the quick response! For now we will not do anything regarding these specific warnings.

One suggestion which I think will be helpful: ideally, the overwrites should be marked with a special tag - for example @Overwrite (similar to the @AllowToRunInFind).
This tag can be added automatically when the option “Overwrite Method” is used.
If the tag is used on something which does not exist in the base form, there should be a warning like “Method <method_name> marked as overwrite but method does not exist in parent/base form”
If someone accidentally creates in a sub-form a method with a name, matching a method in a base/parent form, but without specifying the @Overwrite tag, there should be a warning as it shows up currently.

13

about your return/actual return thing that is already fixed for the next alpha.

We did already talk internally about such a tag. will have to look if we can let that happen for 6, need to see how that can be incorporated into the dltk plugins we use (that are generating the warnings) because that overwrite is very specific to servoy. Can you create a case for this?

14

jcompagner:
We did already talk internally about such a tag. will have to look if we can let that happen for 6, need to see how that can be incorporated into the dltk plugins we use (that are generating the warnings) because that overwrite is very specific to servoy. Can you create a case for this?

The case has been created (Case ID: 362968) Hopefully, the fix can make it in the next alpha/beta - since more and more people are using such overwrites and the Servoy frameworks also rely heavily on base forms, having such tag to mark the overwritten methods will be very helpful.

If there is a voting on what should make it into the next alpha/beta, do count me in on this one!

15

Hi all,

When we try to use the following @param tag to indicate that the parameter accepts multiple types, we get a warning "Unknown object String|Number:

/*
* @param {String|Number} paramName description
*/

This is part of the “standard” JSDoc - is this supported in Servoy? If not, can such support be added?

Thanks!

16

that one is not supported (yet)
but also i am still not really for that one to support that
i really dislike that construct. Because what does that mean? So suddenly code completion and validation must allow both types in that function for that argument
But 1 of them is just illegal and will result in wrong code.
it is way better to split that one into 2 arguments.

17

Hi all,

On several occasions, we experienced an issue where after modifying the existing JSDoc comments for functions in order to resolve warnings in Servoy 6a4 and saving the changes, the JSDoc content is wiped off and replaced by the generic:

/**

  • // TODO generated, please specify type and doc for the params
  • @param {Object} paramName
  • …
    */

In those cases the Servoy Developer gets into some sort of an infinite loop where the @properties UUID constantly gets re-generated and the .js file is constantly being modified and saved (the toolbar “Save” buttons constantly “blink” from enabled to disabled state and the file “Undo” history is lost due to the numerous auto changes and saves). The Developer is not “frozen” and by manually making any change to the .js file “kills” the infinite loop but all changes made to the JSDoc comments are gone. In some cases, the auto-generated JSDoc overlaps with the edits which the programmers are doing in the moment resulting in invalid comment section altogether. We cannot reproduce this issue at will but multiple developers experience the same on different machines.

Has anyone else experienced something similar? Is Servoy aware of this issue and are there any fixes for it? This will be a major trouble for anyone who tries to convert existing code from Servoy 5 (with some already existing JSDoc comments) to Servoy 6 .

18

jcompagner:
that one is not supported (yet)
but also i am still not really for that one to support that
i really dislike that construct. Because what does that mean? So suddenly code completion and validation must allow both types in that function for that argument
But 1 of them is just illegal and will result in wrong code.
it is way better to split that one into 2 arguments.

I disagree with you. Here are my reasons:

  • Such construct is perfectly valid for JavaScript and there are multiple cases where even the Servoy methods are using it. Its meaning is the same as “method overload” in other languages, but JavaScript being a dynamic language allows the “overload” to be handled within the same method.
  • The limitation which you are describing is not of the JavaScript language, but of the Servoy tool - for example the Google JSDoc-Toolkit supports it without a problem
  • If inside the function, specific code applies to one of the supported types, we could use the /** @type {Type} */ tag to give the code completion a hint of what the code actually means. I have no issue if this is a requirement in order to support the multiple types @param tag.
  • Applying some restrictions to new code being developed with the tool due to its limitations perhaps is OK, but I have no justification for such things when I need to refactor 200000 lines of existing code (this is how much we actually have!) to work around the tool limitation. The refactoring in this case cannot be automatic since it requires a new argument to be added to the method signature and the decision of which one to be used in every usage must be done by the programmers.

Hopefully this helps you in your decision to add support for this construct.

19

Hi all,

When specifying method arguments which are custom objects, we can use the @param tag like the one below to specify the different properties of the argument object:

@param {Object} customerArg - customer arguments object
@param {String} customerArg.name - the name to use
@param {Number} customerArg.age - the customer’s age to use
…

Can something similar to this approach be used for the @return tag as well? We have multiple cases where the functions return custom objects and would like to document their properties. I guess, the best way to achieve this will be to create custom “classes” or “types” for the return objects and use those as the type of the @return tag. However, I would like to explore all possible options before deciding which approach we should use.

Any comments or suggestions on this are greatly appreciated!

20

rossent:
On several occasions, we experienced an issue where after modifying the existing JSDoc comments for functions in order to resolve warnings in Servoy 6a4 and saving the changes, the JSDoc content is wiped off and replaced by the generic:

In those cases the Servoy Developer gets into some sort of an infinite loop where the @properties UUID constantly gets re-generated and the .js file is constantly being modified and saved

if you somehow have a trigger when that happens that would be great.
I will try to reproduce this myself.