Developer Preview – February 2019

Developer Preview – February 2019:

Welcome to the February edition of the Developer Preview.

The biggest announcement this month is that we are publishing a preview of the base application fully on AL language.

There is a new Docker image, which contains this version here:

  • bcinsider.azurecr.io/bcsandbox-master:14.0.28630.0-al. 

Currently this image is not automatically refreshed. We will manually push new images with the country code al (and new version number) until we have a process in place to do this for all country codes.

Having the base application fully converted to AL means that it is one big extension with almost 6000 files. To make it easier to work with such a big extension we’ve developed a series of features.

This Developer Preview is available only through the Ready to Go program.

To get all fixes and features described in this blog post

  • please make sure that you are running an image with build number 28630 or newer.

Rapid Application Development (RAD)

RAD is a C/SIDE term used for changing an application object, compiling it, and seeing the results instantaneously in the client.

We have tried to replicate a similar experience for extension development in AL Language in VS Code. More specifically it is about publishing only the objects that changed since the last full publish took place. This is especially useful when working on large projects with several thousands of objects.

We will use the terms “incremental publish” and “RAD publish” or just “RAD” interchangeably.

We have introduced two new commands for doing incremental publishing/debugging. These are :

  • Ctrl+Alt+F5 for incremental publish
  • Alt+F5 for incremental publish and invoking debugging

Please note that:

  •  You need an app to be fully published before at least once before you can use incremental publish for the same app.
  •  You cannot change the version, publisher, and name of the app if you do an incremental publish
  • If things fail for incremental publishing you would need to do a full publishing (Ctrl+F5) before using the RAD features again.
  • A tracking file that captures which files have changed for the purposes of incremental build and publish is created and updated on any developer action that involves a build process. for anything that involves a build (not Save and this is by design). These are the build (Ctrl+Shift+B), or any of the deployment or debugging tasks.
  • A RAD published file will not contain the following files that are normally packaged during regular publishing:
    • translation files,
    • permission files,
    • custom word and report rdlc layout files,
    • table data, and
    • web service definition.
  • RAD does not replace full publishing.

New schema update mode – ForceSync

In this release we’ve added a new data schema synchronization mode. It’s very similar to the existing ‘Synchronize’ schema update mode but with more freedom to make schema changes while retaining data:

  • In the launch.json file, set the parameter ‘schemaUpdateMode’ to ‘ForceSync’
  • Set the app version to <something fixed>
  • Iterate until happy knowing the sync process will let you do everything while preserving data in all of your unchanged tables and fields

Data will be preserved in almost all cases. The only exception is changing the main table’s Primary Key in which case the data from the extension tables will be lost.

Field renames are allowed and supported in this mode, but the data can only be preserved if you maintain the same ID. If you change both the name and the ID of the field than data will be lost.

Please note that this schema update mode is only meant for testing/development and should never be used in production.

The new mode is exposed both through the ‘schemaUpdateMode’ setting in launch.json in VSCode as well as through the powershell cmdlet (Sync-NavApp –Mode ForceSync).

This month's preview contains several other features as well.

Debug without publishing

A new command has been added – Ctrl+Shift+F5 – which will start the debugger attached to the Visual Studio Code launched client session.

Please be aware that if you start debugging without publishing you will be debugging the last published code of your app.

Firefox has also been added to the list of supported browsers that will open a client for a VsCode debugging session.

Debugger info for http, json etc

Variable value inspection has been added for:

  • HttpClient, HttpRequestMessage, HttpResponseMessage, HttpHeaders
  • JsonValue, JsonToken, JsonObject, JsonArray
  • XmlElement, XmlDocument, XmlNode, XmlText, XmlComment, XmlCData, XmlAttribute

Code actions

Code Actions is a VS Code feature providing the user with possible corrective actions right next to an error or warning. If actions are available, a light bulb appears next to the error or warning. When the user clicks the light bulb (or presses Ctrl+.), a list of available Code Actions is presented. We introduced the extensible framework to provide the actions feature support in AL.

There are two code actions available in the current version:

  • Multiple IF to CASE converting code action
  • Spell check code action.

TableRelation extensibility

The TableRelation property on table fields can now be modified in a table extension. The modifications to the TableRelation is additive and are evaluated after the existing value. The primary use case is conditional table relations based on conditional enums.

For example, in one app a table is defined like below:

Another app could then extend both the enum and modify the table relation to also handle the extended enum with the code below:

The combined table relation is evaluated top-down. That means that the first unconditional relation will prevail, i.e. you cannot change an existing TableRelation from Customer to Item, since the original table relation is unconditional.

Views

Views offer a way to improve user productivity when working with list pages by proposing an alternative view of the page that contains:

  • Filtering of the data on multiple table fields.
  • Sorting of the data on multiple table fields (but only in one direction: ascending/descending).
  • Layout changes, modifying page columns, moving them, etc. 

Defining views in AL

Unlike V1 views which were defined as part of the RoleCenter, V2 views in AL are now defined on the list page itself.  Views are defined in a dedicated views section that contains an ordered list of views.

Note:  You can use IntelliSense and the tview snippet in order to help you get started!

Views are also integrated in the extension model. It is then possible to create, re-order, or modify views in a page extension or in a page customization. With the version, you get the development story for creating views, later the end-user will be able to create views using Designer.

Filtering and sorting

Filtering in views is achieved by using the new property Filters. The property syntax is similar to the other properties you can use to apply filtering on a page in AL (like SourceTableView on a page, or RunPageView on an action).

The syntax is composed of a where clause with a list of filters defined with a filter name, the equal sign, the type of filter and the filter value to be applied:

Ordering

Ordering is achieved by using the property OrderBy. The property syntax is similar to the OrderBy property that exists on a Query. It is used to specify one sorting direction on a set of table fields. Currently the language allows you to specify only one sorting direction.

Note: The filters are applied on the table fields, not on the page fields. It is then possible to filter on a table field even if this table field is not shown in the page. However, if a page field has a variable as a source expression, it is not possible to use it.

Modifying the page layout

It is possible to modify the page layout of views, the same way it is possible to modify it from a page customization. This includes modifying some properties on page controls and/or moving them. It is not possible to add new page controls in a view.

Modifying views from extensions/customizations

Like action and controls, views can be moved using the moveafter, movefirst, movelast and movebefore constructs. It is also possible to modify the visibility of a view (hide/show it) and to modify its caption (rename). Those are the only two properties that are available for modification from extensions in a view. If a developer wants to modify a view’s filter, the advised approach is for him to create his own copy of the view. The rationale being this decision is that views are already a ‘delta’ of the page due to the layout section that they contain. So modifying the view’s layout would have been like applying a delta of a delta which is a completely new (and probably also confusing) concept.

When modifying views from extensions, IntelliSense can also help you to know what you can do or not.

Things you cannot do in views (by design)

Views can be seen as a page customization embedded at the page level and that is triggered when pressed in the UI. As a consequence, a view has the same capabilities (and limitations) as a page customization:

  • The control properties that are modifiable in a view are the same ones that the properties that are modifiable in a page customization independently of where the view as been defined (page, page extension, or page customization level). This is validated by the compiler.
  • It is not possible to use variables or methods in a view. When writing client side expression for properties like Visibility, it will only be possible to use constant values or table field references. This is validated by the compiler.
  • It is not possible to create new controls for a page from a view.

Visualizing Views in the Web client

V2 views are rendered below any V1 views in the filter pane of the Web client. They are always visible on the view page no matter how the page was accessed.

AllObj and AllObjWithCaption no longer contains obsolete Tables

The ‘AllObj’ and ‘AllObjWithCaption’ virtual tables no longer contains obsolete tables.

Comment List
Related
Recommended