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.