Stoc |
---|
...
Servoy 6 offers some amazing new features in the Servoy Developer IDE when it comes to designing forms and writing business logic.Part of the latter is a greatly improved JavaScript code validation: the entire code base of a solution will be continuously checked for possible coding mistakes, like accessing or setting non existing features a greatly enhanced build mechanism that checks the validity of the design of a Solution while it is being designed. As a result of this improved build system, existing solutions that get opened in Servoy Developer 6 will most likely contain a lot of Problem markers.
It is important to note that these Problem markers are of the level "warning", meaning that it doesn't necessarily mean something is broken!
The majority of the generated Problem markers are most likely related to the JavaScript code contained in the Solutions, as this is one of the area's where the most improvements were made, but some work is required by the developer to get the best results. More on this is discussed below, in the Improved design-time JavaScript code validation alinea.
Another area where Problem markers are raised that were not raised before is the area of using deprecated scripting API. With every release Servoy improved the capabilities in the scripting API. This sometimes means deprecating parts of the API in favor of new and improved API. Deprecating API means that it is marked as "Should not be used anymore", while it continues to function. In servoy deprecated scripting API is hidden in developer.
As of Servoy 6, Problem markers will be generated on the JavaScript code that accesses deprecated API. The API will still function as before, the Problem markers are just an indication that the used API is marked as "Should not use anymore" and that at one point in time the code ought to be rewritten to utilize the new way of doing things. The #Deprecated API alinea below provides an overview of the API that got deprecated in Servoy 6.0 and what the replacement functionality is.
Servoy 6 features greatly improved design-time JavaScript code validation: the entire code base of a solution will be continuously checked for possible coding mistakes, like accessing or setting non existing variables, calling non-existing methods or calling methods with the wrong number or type of parameters.
...
The new script validation in Servoy Developer 6 however tries to determine if the the properties you access actually exist, if the method you call exist and if you call them with the right number and type of arguments. The validation mechanism tries to be as clever as possible to determine which code is correct and which code isn't, but due to the weak-typed (and dynamic) nature of JavaScript, somethings sometimes clever logic just isn't enough and the validator requires more input from the developer in order to do proper validation. This developer input is done in the form of JSDoc.
While previous versions of Servoy already had support for JSDoc, in Servoy 6 this support has been extended and improved, in order to better facilitate the validation process. So, while you might get numerous warnings once you open your existing solutions in Servoy 6, remember that these are just "warnings", not errors, they do not mean that your solution is not working. For more information on annotating JavaScript using JSDoc see Annotating JavaScript using JSDoc.
While we advise to solve the warnings, so you can also reliable start using some of the other great features of Servoy 6, like automatic code refactoring or search for references, you can ignore the warnings. It's even possible to turn off all the warnings, see Window > Preferences > JavaScript > Error/Warnings.
Do note that automated refactoring, Search for References or JavaScript Search might not be 100% complete if JavaScript is not properly annotated using JSDoc, due to which the JavaScript code cannot be fully analysed automatically.
The list of deprecated properties in the Designtime API is limited. Except for the deprecation of the "rowBGColorCalculation" on Forms and Portals, the deprecation of the properties require no action on behalf of the developer, as Servoy Developer will automatically handle the changes.
...
Object | Deprecated method or property | Replacement | Comment |
---|---|---|---|
Form | extendsForm | extends |
|
| rowBGColorCalculation | CSS Row Styling & onRender event |
|
Portal | resizeble | resizable | Fix typo |
| rowBGColorCalculation | CSS Row Styling & onRender event |
|
TabPanel | onTabChange | onChange |
|
The majority of the deprecations in the Runtime API are related to the new windowing API and the refactored HTTP plugin.
Object | Deprecated method or property | Replacement | Comment | ||
---|---|---|---|---|---|
controller | .getContainerName() | controller.getWindow().getName() |
| ||
Button | .setBorder() | .border | Matching getters or setters added, allowing both getting and setting the value. | ||
RuntimeLabel | .getParameterValue() | N/A | Never worked properly | ||
Date | .setYear() | .getFullYear() | This function is deprecated in the JavaScript specification | ||
Application | .getStartupArguments() | onOpen event handler of the solution | Deeplink arguments are now passed to both the onOpen event handler of the Login and Main solution. | ||
| .closeForm() | JSWindow.hide() | Servoy 6 contains a complete new Windowing API. A window or dialog is now an instance of the JSWindow class to which a lot of the methods have been moved. New methods were added to the application and controller objects to interact with windows | ||
| .getWindowHeight() | JSWindow.getHeight() |
| ||
| .getWindowWidth() | JSWindow.getWidth() |
| ||
| .getWindowX() | JSWindow.getX() |
| ||
| .getWindowY() | JSWindow.getY() |
| ||
| .setWindowLocation() | JSWindow.setLocation() |
| ||
| .setWindowSize() | JSWindow.setSize() |
| ||
| .showFormInDialog() | application.createWindow('name',JSWindow.DIALOG).show('formName') | The method application.createWindow(..) returns an object of type JSWindow, which has an Scripting API to control additional things like the title, resizability, initial bounds and whether or not to show a textToolbar | ||
| .showFormInWindow() | application.createWindow('name',JSWindow.WINDOW).show('formName') |
| ||
UICONSTANTS | .FULL_SCREEN | JSWindow.FULL_SCREEN |
| ||
JSForm | .rowBGColorCalculation | CSS Row Styling & onRender event |
| ||
JSPortal | .resizeble | .resizable | Fix typo | ||
| .rowBGColorCalculation | CSS Row Styling & onRender event |
| ||
JSTabPanel | .onTabChange | .onChange |
| ||
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="24754f189a6f54b5-fef5b548-4fa94bcb-8795b61f-9c234f68130fa5c3299cdccc"><ac:plain-text-body><![CDATA[ | databaseManager | .getFoundSetDataProviderAsArray() | .convertToDataSet(['dataProviderId']).getColumnAsArray(1) | Duplicate functionality | ]]></ac:plain-text-body></ac:structured-macro> |
ServoyException | .INVALID_INPUT_FORMAT | N/A | never raised | ||
plugins.file | .getHomeDirectory() | .getHomeFolder() | Match naming convention | ||
| .getRemoteList() | .getRemoteFolderContents() | Match naming convention | ||
plugins.http | .createHttpClient() | .createNewHttpClient() | The HTTP plugin was refactored to support all types of HTTP Requests and support more finegrained control over the requests. Instead of creating an HttpClient and referencing it by name, the HttpClient is now an object with it's own set of methods, for example methods to create all the different types of HttpRequests. Each XxxxRequest object has a .executeRequest() function that returns a Response object again with it's own methods. | ||
| .deleteHttpClient() | N/A | No longer required | ||
| .getHttpClientCookie() | .getCookie() on HttpClient object |
| ||
| .getHttpClientCookies() | .getCookies() on HttpClient object |
| ||
| .getLastPageCharset() | replaced by .getCharset() on Response object returned by the .executeRequest() method on any of the XxxxRequest objects created by the .createXxxRequest() methods on the HttpClient object |
| ||
| .getPoster() | .createPostRequest() on HttpClient object |
| ||
| .put() | .createPutRequest() on HttpClient object |
| ||
| .setClientProxyUserNamePassword() | .setClientProxyCredentials() on HttpClient object |
| ||
| .setHttpClientCookie() | .setCookie() on HttpClient object |
| ||
plugins.window | setToolBarVisible() | .setToolBarAreaVisible() | Name now matches what the function does | ||
MenuBar | .validate() | N/A | No longer required |
...