rossent:
jcompagner:
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.
But if you then want to do you own casting then just do
@param {Object}
and inside the function you do:
@type Number
when you use it as a number…
jsdoc toolkit doesn’t really do anything with it. But in dltk we need to give that parameter 2 types and also check all calling methods for those 2 types, thats quite some work.
Also a second approach would be to use the thing you specified below:
@param {Object} customerArg - customer arguments object
@param {String} customerArg.asastring- the name to use
@param {Number} customerArg.asanumber - the customer’s age to use
rossent:
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.
we are looking into something like:
@return {{astring:String,anumber:Number}} My return object with a string and number argument.
the only thing is you can’t document the actual property itself.
Hi all,
What is the correct way to document the custom “types” in Servoy so the code completion works correctly and we do not get unknown type related warnings?
The attached solution contains some sample code along with the warnings which we are getting. In this particular case, we use a separate form as “container” for the custom type, however that same happens if we try the global scope (i.e. CustomType = function(…){…}
- in that case there is the added warning for using an “undeclared variable” which is OK (ideally, there should be an option to turn off individual line warnings)
Here is the scenario:
In form named “obj_lib” we define a function which is the constructor for the custom type/class like:
/**
* @constructor
* @param {String} _name some description
* @param {Number} _age some description
*
* @properties={typeid:24,uuid:"386B4857-1672-4F01-AEA1-229BEC001A95"}
*/
function CustomType(_name, _age)
{
/** @type {CustomType} */
var _parent = null;
this.name = _name;
this.age = _age;
//special case when we use the third argument to specify the parent
if(arguments.length > 2)
{
var _p = arguments[2];
if(_p instanceof CustomType)
{
_parent = _p;
}
}
/**
* @return {String}
*/
this.prettyPrint = function()
{
//here code completion for "this" does not work
//"this" is not seen as CustomType
return 'Name: [' + this.name + '] - Age: [' + this.age + ']'
};
/**
* @param {String} _childName
* @param {Number} _childAge
* @return {CustomType}
*/
this.createChild = function(_childName, _childAge)
{
//this works without any warnings
return new CustomType(_childName, _childAge, this);
}
/**
* @return {CustomType}
*/
this.getParent = function()
{
//here CustomType is not recognized;
//getting warning: "Function <anonymous> declares CustomType as type but returns Object"
return _parent;
}
}
When using the custom type in another form:
/**
* @return {forms.obj_lib.CustomType} <- this produces the warning "Function prepareObject declares forms.obj_lib.CustomType as type but returns forms.obj_lib.CustomType"
*
* @properties={typeid:24,uuid:"04A231B2-AC12-4B17-9C42-F80F19E49272"}
*/
function prepareObject()
{
//this extneds correctly the CustomType and adds the newMethod to it
//however there is a warning: "The static property Function.prototype should be accessed in a static way"
forms.obj_lib.CustomType.prototype.newMethod = function(){application.output('new method');};
//the object instance is created correctly
var _parent = new forms.obj_lib.CustomType('The Parent', 42);
//this works at runtime, however at design time produces the warning: "The function newMethod() is undefined in this script"
//basically, anything added through the prototype is not reflected on the Intelisense
_parent.newMethod();
//the code below works and there are no warnings
var _child = _parent.createChild('The Child', 16);
application.output(_child.prettyPrint());
return _parent;
}
/**
* @properties={typeid:24,uuid:"5D4ED946-3CEB-4E9C-9B20-E4B89385041A"}
*/
function useObject()
{
//this works and there are no warnings
var _parent = prepareObject();
application.output(_parent.prettyPrint());
doSomething(_parent);
}
/**
* @param {forms.obj_lib.CustomType} _person <- this produces the warning: "Unknown type forms.obj_lib.CustomType"
*
* @properties={typeid:24,uuid:"D1C0AB55-39A0-4506-8DE1-AB3BD60DE08F"}
*/
function doSomething(_person)
{
//this works at runtime, however at design produces the warning: "The function prettyPrint() is undefined in this script"
//since the custom type is not recognized, the code completion for _person does not work at all
application.output(_person.prettyPrint());
}
Any ideas on this are more than welcome!
custom_classes.servoy (4.54 KB)
rossent:
What is the correct way to document the custom “types” in Servoy so the code completion works correctly and we do not get unknown type related warnings?
…
The issue with extended methods and properties not being supported by the code completion and code analysis applies also for example if mod_datejs is used - none of the added class or instance methods are visible which is a pity. Developers have to refer either to the source code or some outside reference materials for the correct method names and used arguments, and after that the code analysis still shows up invalid warnings/errors. What will it take to allow the tool to support those cases and provide as much as possible automatic assistance to the developers? For example, the IntelliJ IDEA JavaScript editor handles these cases, so obviously it is technically possible to have such support regardless the dynamic JavaScript nature. Servoy 6 is already much, much better from the version which we started to use it and we greatly appreciate all the efforts which the Servoy team has put into this product. But as a great tool/platform it will always be compared to the best out there and the developers would always want all the bells and whistles which make their daily work easier.
Xxxx.prototype.yyy = function(){}
will not be supported in the ide. this is something that just can’t be done, it is completely dynamic.
For example you could add your prototype method in function somewhere in a global.js file in some kind of module
and later on in a form.js file in another module expect to have it there. That is just something we just don’t know.
Thats only there are runtime
Because it is pretty dynamic the call to yyy function that generates the warning can be circumvented by using it dynamically
myobject’yyy’
I will also look at the jsdoc custom type problem. Code completion/Type Inferencer knows what you are doing so thats why it works for them
problem is that we currently don’t really have support for “package” type scopes, so with a “package” prefix.
Hi all,
On several occasions we experience the issue where after adding/modifying JSDoc comments, the TAB key stops working in the Script Editor. Have not isolated what changes exactly cause this issue but there are some indications that perhaps adding/modifying /** @type {Type} */ inline comments have something to do with this. When the issue occurs, pressing the TAB key does not indent the source code line, however SPACE still works.
Some additional info: in our case we use the default setting to insert spaces instead of tabs and a customized formatting template which was working fine in 5.2.6
Has anyone else experienced this and are there any workarounds?
jcompagner:
Xxxx.prototype.yyy = function(){}
will not be supported in the ide. this is something that just can’t be done, it is completely dynamic.
I completely understand the technical difficulties involved in supporting this.
How about if providing such support requires that these xxxx.prototype.yyy = function(){} extensions (or even the custom classes/types) are limited to specific .js files and/or these .js files have to be “registered” within the Servoy Developer (this way you will know the code from which files should be “parsed” at design time to extend the code-completion)?
This will be a perfectly acceptable option for us and is the approach used by some other JavaScript editors to work around the dynamic nature of the language.
ok i have found a way to resolve this:
/**
* @param {forms.obj_lib.CustomType} _person
*/
function doSomething(_person) {
application.output(_person.prettyPrint());
}
the jsdoc type checker does find that now and also code completion works.
Jan Blok:
It might be needed to enble displayTags on the element to process the titleText at all outside tableview
In a Record View, this does not work regardless the displayTags setting.
In Table View, the links are displayed only if no label is associated with the HTML_AREA element (using the labelFor property), however even when displayed, the links are really not “clickable” (clicking on any of them results in the standard column header click).
I really am having a hard time understanding how exactly this feature is intended to be used. Can someone provide a sample solution for this?
Any update on when the next alpha release of Servoy 6 can be expected?
Hi all,
We experienced today several crashes of Servoy Developer due to running out of memory. It appears that the the issues started after using for a short period of time the new Search for References (Ctrl+Shift+G) and/or JavaScript Search (Ctrl+H) options. The memory usage was constantly growing and nothing was being released back even after running manually the garbage collector (the option at the bottom of Servoy Developer). Perhaps there are some memory leaks related to this new functionality which should be taken care of.
Has anyone else experienced similar issues?
How much memory do you have assigned to Servoy developer?
In 6.0 you do need more memory then in 5.2 because there a loads more generated (The whole Type structure of all the types that are possible are generated when needed and thats quite a lot)
I am testing with a big solution, will do some more testing, but can you look what really triggers it for you?
jcompagner:
How much memory do you have assigned to Servoy developer?
In 6.0 you do need more memory then in 5.2 because there a loads more generated (The whole Type structure of all the types that are possible are generated when needed and thats quite a lot)
I am testing with a big solution, will do some more testing, but can you look what really triggers it for you?
I personally use the default memory setting which comes in when installing Servoy (not sure how much is that, looks like 512MB)
I just had to restart the Servoy Developer again due to the same issue. Before the prior crash, I moved several from variables which are meant to be used as constants to a different form and I wanted to change all references to them. And 2 crashes before that I set all warnings to “Ignore” hoping that it could help a bit with the memory issue (there were still a bunch of JSDoc warning showing up though). This time all I really was doing is this:
- Open a form script, selected a form variable and used the option Ctrl+Shift+G to find all references to it.
- From the search result pane double-click on the found entries which opens the respective script file.
- Make adjustments to the referenced code, save the file and close its tab so I am back to the first file.
- Repeat the same with the next found references
- Repeat the same with another form variable
I know that Search & Replace can do some of that as well and this is what I tried first when I got the first crash. So I decided to try this approach but after working on less than half a dozen files the Servoy Developer memory was back at about 490MB so I just closed it and reopen again… Kind of frustrating experience today with the crashes… Up to now I did not notice such issues with Servoy 6 but I did not try to use these new options extensively before - hence the suspicion that they have to do something with it.
Some additional info: The solution which I am working on at the moment is quite big (~200000 LOC in the .js files) with about 40 modules in the whole workspace, the active solution referencing about 20 other modules.
i guess you guys have the same kind of large solution as TMA and yes then you do need a bit more memory at the moment
if you set it to 700MB or something like that does it still grow beyond that?
I will try to get the memory usage more down, but that is not really simple to do at the moment anymore, Especially if you have a large amount of modules.
It would be nice to somehow have another big solution or have the memory dump at the moment it crashes with out of memory you can do that by setting this as a jvm argument in the servoy.ini file:
-XX:+HeapDumpOnOutOfMemoryError
Unfortunately, sending you the complete solution will not be possible. I made the requested changes to the servoy.ini file and increased the memory to 768MB. Here is what the file looks like now:
-startup
plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.1.R36x_v20100810
--launcher.XXMaxPermSize
256m
-vmargs
-Xms40m
-Xmx768m
-XX:MaxPermSize=256M
-XX:+HeapDumpOnOutOfMemoryError
Will report back with any updates
Is there any UI option in Servoy Developer where we can increase memory after installation?
JC
no this has to be done in the servoy.ini file
Hi all,
We just discovered an issue: the form datasource property cannot be set on forms which extend a base form with no datasource selected.
To reproduce it, follow these steps:
- Create a base form which is not based on a table - the datasource is not selected and shows up as -none- in the property editor.
- Create a child form, and in the “New Form” wizard specify that it extends the base form, select a table for it and some data providers
- Notice that when the form is created, the data providers are placed correctly on the new child form, however its datasource is set to -none- and the property editor does not allow a datasource to be selected!
Possible work-around is to either create the child form initially without specifying the “extendsFrom” and only after the form is created to select its base form from the property editor. A second approach is to manually modify the .frm file and fill in the datasource property
A case is created for this: 363895
This is a huge issue for us since most of our application forms have to extend some base form. Existing form are OK - the issue applies only to new forms created in Servoy 6. Hopefully a fix for this can make it in the next release.
jcompagner:
i guess you guys have the same kind of large solution as TMA and yes then you do need a bit more memory at the moment
if you set it to 700MB or something like that does it still grow beyond that?
I will try to get the memory usage more down, but that is not really simple to do at the moment anymore, Especially if you have a large amount of modules.
It would be nice to somehow have another big solution or have the memory dump at the moment it crashes with out of memory you can do that by setting this as a jvm argument in the servoy.ini file:
-XX:+HeapDumpOnOutOfMemoryError
This is getting into a much bigger issue for us. Even after increasing the max memory which can be allocated to the Servoy Developer (I tried all the way to a 1GB), the issue is not resolved but rather postponed. After about an hour or so all the allocated memory is used up (even if the reference search is not being used), everything in the Developer starts crawling and we are forced to close and restart it in order to be able to continue to work. Definitely there are some memory leaks which should be plugged. I guess this can be reproduced even with a smaller solution, just allocate less memory for Servoy Developer in order to hit that mark sooner.
is the memory dump generated when you get an out of mem with the HeapDumpOnOutOfMemoryError setting?
Can you 7zip it and give servoy an url where i can download it?