Changes in Behavior for Migration to 3.6-3.7

The following changes in behavior apply to migration from 3.5 to 3.6-3.7:

• The <resourcename>.meta.xml file has been deprecated in General Interface 3.6-3.9, so that localized applications that use the file will fail to display localized text.

If you use <resourcename>.meta.xml in your application, update the application to add the locales specification in the main resource properties file. For example:

<data jsxid="jsxroot" jsxnamespace="propsbundle"

locales="fr,zh_TW">

<locale>

<record jsxid="Line1" jsxtext="This old village" type="jsxtext"/><record jsxid="Line2" jsxtext="not a single house" type="jsxtext"/><record jsxid="Line3" jsxtext="without persimmon trees" type="jsxtext"/><record jsxid="Dialog1" jsxtext="Dialog Title (No Chinese or French value available)" type="jsxtext"/><record jsxid="Tools1" jsxtext="Tools" type="jsxtext"/><record jsxid="Display English" jsxtext="Display English"/><record jsxid="Display Chinese" jsxtext="Display Chinese"/><record jsxid="Display French" jsxtext="Display French"/><record jsxid="Display Default" jsxtext="Display Default"/><!-- demonstrates fall-through ></locale></data>

* XML load API uses different protocols in 3.6-3.7 than in previous versions. For releases through GI 3.5.1, the native XML Document object is used and loads XML resources synchronously. Relative path XML resources are resolved relative to the JavaScript code or project configuration file.

For releases starting with 3.6, jsx3.net.Request is used to load XML resources. The major advantage is that this allows for asynchronous loading of resources. However, this also changes the relative path resolution to be relative to the launch HTML page location.

• If your application uses a relative path for the XML resource, you must update the relative path to be resolved by calling <my_application_server>.resolveURI(<my_relative_path>) before passing it to load method such as Document.load(). It is a recommended good practice to always use resolveURI() to specify the resource URL.

• In 3.5, a component loaded from a URI beginning with JSXAPPS/... has its URI resolver set to the application server. In other words, Model.getUriResolver() returns the server of the component when called on the component. Therefore, any path resolved against the component will resolve relative to the project directory.

For releases 3.6-3.7, a component loaded from a URI beginning with JSXAPPS/... has its URI resolver set to jsx3.net.URIResolver.USER. Therefore, any path resolved against the component will resolve relative to the user workspace.

A URI beginning with JSXAPPS/... is considered to be absolute (the same as jsxuser:///JSXAPPS/...) and is supported only for legacy reasons.

Specifically, if you load a component from a URI beginning with JSXAPPS/..., paths that resolve against the component and are relative to the project directory no longer work. The following examples show methods with path parameters that are resolved against the component, such as Model.load(), Cacheable.setXMLId(), and ToolbarButton.setImage().

For example, the following works in 3.5, but will not work in 3.6-3.7

var dlg = myApp.getBodyBlock().load("JSXAPPS/sampleApp/components/dialog.xml");

  dlg.load("components/matrix.xml");

Instead, the recommended approach is to load all components with project-relative URIs:

var dlg = myApp.getBodyBlock().load("components/dialog.xml");

  dlg.load("components/matrix.xml");

The following deprecated option uses all legacy URIs:

dlg = myApp.getBodyBlock().load("JSXAPPS/sampleApp/components/dialog.xml");

  dlg.load("JSXAPPS/sampleApp/components/matrix.xml");

For Model.load(), which accepts an optional URIResolver parameter, you can explicitly specify the resolver:

var dlg = myApp.getBodyBlock().load("JSXAPPS/sampleApp/components/dialog.xml");

  dlg.load("components/matrix.xml", true, myApp); // 3rd parameter is the resolver.