Version 2.19 - incremental regular release

Release notes for version 2.19.0

Local Proxies (LocalAPI/LocalAPIClient/AppGate etc.)

The Local proxy support has been further improved with support for Operation and ChunkedOperation as return results of methods called through local proxy

Added a translator support in EventDispatcher which can be used for other purposes as well. Local proxies now use one when the client of a locally proxied call subscribes to events of the service server to translate the arguments of the event when passed to the handler. It is using the same behavior (Arguments declaration and proxy clone) as the translation for method calls, but in the reverse direction (server to client).

LocalProxyCollection is updated to support second optional parameter in the constructor. It specifies the interface for all the items. Services can now fill and return collections from which items can be obtained with the most useful interface directly without the need to call GetInterface in an additional step.

DOMUtil

Several small additions

fromDOMElementOffset

now returns an empty Rect instead of null when the size and pos of the element cannot be determined (e.g. if the element is not displayed).

Target binding operations

All the target operations for data-bind bindings are rewritten and no longer use jquery.

A few new target operations have been added - e.g. addclass[classname], display etc. There is an updated page in the documentation with the full list and description.

Operation

All operation related classes now support additional handling methods - onsuccess, onfailure and the same methods are also supported by the SuggaryDispatcher. In practice this means that op.onsuccess(function(result) {...}) and op.whencomplete().onsuccess(function(result) {...}) will work the same. This applies also to onfailure and a couple of other old and new methods.

Niche problems with "late clients" are now fixed for all the cases.

HistoryState

This feature has been updated to work through local proxies and apps can obtain it as LocalAPI and push states as desired.

Memory FS additions

Added predefined location infofs:/appinfo/[AppClass] - intended for files describing certain details for an app. Features that need such details can define filenames they seek and read them when supplied for the apps opting for the feature.

(in development) An user profile app used in our projects uses the above feature to build global settings UI from settings descriptions published in appinfo. This way there is no need to launch the app in order to acquire the needed information.

Bindings

Support for a new option - operation is added to data bindings. If specified if an operation is being transferred to target the binding will wait it and update the target when the operation completes. Without the option the operation itself will be passed to the target. This enables both behaviors to be exploited as necessary.

Validation

All rules have been reorganized and placed in separate files. Minor fixes were made in some.

Validator has been extended to support importRules parameter that can be filled through initial binding (in data-class parameters) from any place in the apps code. This way the rule set definitions can be moved outside the mark-up of the view and reused with much less effort across all the views of the app. Additional options were added - like dynamic rule set replacement (rarely needed) and so on.

Most of the the validation rules have been checked and corrected to validate values only if they fall in their validation domain. Effectively this was the convention, but some mistakes were found, which caused the code auditing. What this means in practice is that some rules have been checking for both "required" and their own validation, which is incorrect as it prevents the programmer from validating optional fields.

ITranslator, ITranslatorProvider

A new concept for granular level IoC has been introduced. Translators are supposed to implement data extraction/conversion from one form/type to another. This may vary - from extracting a few properties from an object and returning them as a specific type, to pure conversion of one type to another that presents the same data differently (adapted to other uses/API etc.). This is part of the process of implementing interfaces and implementations of specific and more general operations often used in the code of various methods. The classes to which they belong can provide the tool that performs the operation (ITranslator in this case, IValueChecker - one that was introduced previously).

The benefit is not only the usage of existing implementations - this can be done as good old functions after all. It really makes difference because these small operations can be supplied with IoC on granular level, such as setting a property with the appropriate implementation and writing code that just uses it, thus making possible to impact the way the code works from outside. Another way is to use this in a host/guest pattern where the guest requests the tool from its host thus allowing the host to specify a conversion type without the need to change the guest's code when different conversions are necessary.

Interfaces for access to db-like data through local services

IManagedDataProvider and IManagedDataSupplier define rules and contract for exchanging db-like (table-like) data through local services. The Local services (accessed through Local API or through known apps) are the ones using local proxies to isolate client and server apps. In most cases they implement higher level abstraction for data access. For example they can use specially created classes for wrapping data in "smart" objects that provide methods to obtain related data (again wrapped in similar fashion). E.g. accessing data in ORM fashion. This is of course not the only way local services can provide access to data for their clients, but some general cases can be recognized and one of them is the usage of local services to provide data they obtain from somewhere as raw as possible. IManagedDataProvider and IManagedDataSupplierare defined for these cases and they define the interface and pattern of behavior. On this contract a new connector is also included in BK 2.19 - DataSupplierConnector. It provides the connector functionality over these interfaces enabling the option to connect for example a DataArea to data streamed through some Local service.

Minor fixes and additions of note

Removed appname argument from BkInit.KeylaunchMenu

Added data viewer template in BindKraft to make possible to use the component without supplying template externally

PagerControl now is able to autolink to the DAtaArea without the need to point events to its handlers manually.

callbacks of all forms of ImplementProperty can be now specified in-place and not only as a member name. They are called with the object as this, so nothing changed in the behavior, but single-use callbacks now do not require you to define them as regular members.

Critical error in OperationAggregate has been fixed. It affected OperationAll as well. The effect was (valid for 2.18) that the operations were not waited properly and the aggregate often completed before all of them.

InfoDisplayWindow, InforDisplayPanel was resurrected and fixed. This includes a default template in BindKraft. However the displays are all off by default and one needs to enable them where needed.

Remarks

The deprecated features scheduled for removal (in comments and docs they were scheduled some for 2.19, some for 2.20) will all be removed in 2.20. We noticed that there are a few more (probably completely unknown and may be never used), so this will be done all in one step with the next regular release.

Further code clean up is planned and may be also completed with the next release, but this may be delayed to 2.21 if the time is not enough.This includes at least 20-30 files (outside of trashbox and inprogress directories) and may be even more than that.

Javascript files not listed in the corresponding .dep files should not be used! These are either new unfinished features or old deprecated ones scheduled for removal.

BindKraft v2.18.0

This is the first release after moving the development to GitHub, some fixes may be necessary since we are still getting used to GitHub.

The 2019-Jul-11 Release includes a number of new features, mostly deep inside the platform, and intermediate results of long term efforts.

Highlights:

• The old and short lived mechanism of passing queryback (based on ILauncherQueryBack - deprecated too) object to apps by the shell has been deprecated. It is still supported, but old apps will have to implement IRequiresQueryBack marker interface to request the old shell behavior (will be completely removed in v2.20)
• LocalAPI related app interfaces IImplementLocalAPI, ILocalAPIImports, IUsingLocalAPI and the related implementors are also deprecated and will be removec in v2.20. They currently work, but it is recommended to migrate to AppGate usage as soon as possible.
• The local proxy system has been drastically extended and improved to support events (EventDispatcher-s) in the interfaces, releasing of the proxies and release containers that automate this process almost completely.
• AppGate is introduced. An object of that class is created by the shell and passed to the constructor of launched app, providing it with a ready to use LocalAPIClient (hidden behind AppGate's methods) and set of methods for querying running apps for services. Both LocalAPI and app services are returned wrapped in local proxies registered in the release containers maintained by AppGate and LocalAPI for the life-time of the app. They are automatically released when the app shutdowns. Each proxy will self-unregister from its container if Release() method is called on it explicitly, thus giving the programmer a chance to both save some memory by explicitly releasing unneeded references to services and API and not suffer fatal consequences if explicit action is not taken (releasing them when the app shuts down).
• IAppDataApi local API is now available together with BKIinit.AppData enabling small data pieces to be configured to load in memory and used as configurations or handy content by apps
• First surrogate app was added - TabbedSurrogateApp, but it is still in early stage - working, but very limited.
• LightFetchHttp class is added to allow alternative simple ajax communication. Further AJAX development will use and extend it in future versions, involving this class in more complex AJAX pipeline. For now only direct usage of the class is available for same origin requests (for now).
• Added datatoURL static method in BKUrl to enable conversion of plain javascript objects to query string parameters with arbitrary depth
• Fixed acticateWindow bug which occurred only with 3 or more topmost windows visible at the same time.
• The removal of JQuery usage progresses and DOMUtilElementClass and DOMUtil set of methods grew considerably as well as their usage. Bindings now support direct (not through Jquery) target operations, but only a few are replaced for the moment and they fall-back to jquery for the rest (this will be completed in 2.19)
• A lot of new documentation articles were added to the Documentation folder.