Child pages
  • Upgrading to Servoy 7.x.x

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

 

Stoc

Upgrading installations

Upgrading Servoy Application Server

...

Resolving warnings and errors

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.

Improved design-time JavaScript code validation 

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.

(warning)  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. 

Deprecated API

Designtime API

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

 

Runtime API

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
Label
Fields
Rectangle
TabPanel
SplitPane
Portal

.setBorder()
.setFont()
.getTitleText()
.setImageURL()

.border
.font
.titleText
.imageURL

Matching getters or setters added, allowing both getting and setting the value.
Not all mentioned properties are applicable to each mentioned type of object

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.
The .getStartupArgument() is therefor no longer required to get access to the startupArguments prior to login

 

.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')
application.createWindow('name',JSWindow.MODAL_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
Toolbar

.validate()

N/A

No longer required

...