 |
| ||||
Durandal is a cross-device and cross-platform toolkit for developing Web based applications that run mainly in JavaScript.
The framework uses many well-known technologies jQuery, Knockout, Bootstrap, Sammy and RequireJS to provide an MV (mode-view-no-controller) environment for writing, deploying and running top of the line applications.
Here are some key features of "Durandal":
· Modular architecture
· Events manipulation
· Easy UI prototyping
· Async and Promises support
· Bundling and optimization tools
· Easy templateable layout
· MVC-MVP-MVVM compatible
· Mobile friendly
· Documentation
Requirements:
· JavaScript enabled on client side
What's New in This Release: [ read full changelog ]
· Massive reorganization of the github repo. The reorg was done to cleanly separate the library, samples and starter kit source from the platform targets and to facilitate a cleaner build process with less manual "fixup" as the list of supported platforms expands.
· Durandal now expects to live along side 3rd part script libraries, outside of your application code. All samples and starter kits have been updated to use requirejs.path to setup the correct mapping, per platform. Additionally, the framework no longer assumes that plugins or transitions are under the durandal folder. The starter kits all use requirejs.path to map them to their actual location.
· Durandal no longer has any dependencies on globally defined variables. It now requires everything through the module system. This means that jQuery and Knockout must be defined in order for Durandal to function properly. The samples/starter kits all set up the proper requirejs.path and shim config to make this happen.
· There is now an official plugin model which should be configured before calling app.start. This allows plugins to load in, adding binding handlers and extending durandal APIs before your application code runs. You can pass configuration to the plugins as part of this process. Once the plugin model was in place we moved several libraries out of the core and into plugins. These include: dialog (formerly modalDialog), widget and http. Additional plugins shipping with Durandal 2.0 include: router, history, serializer and observable. Plugins which should be directly installed with the new plugin system include: router, dialog, widget and observable (optionally).
· The modalDialog module was renamed to "dialog" and changed to a plugin. The messageBox module's source and view are now part of the dialog module. Formerly, showing a modal added a "modal" property on to the shown module which could be used to close the modal and return a value. This is no longer the case. Closing and returning a value should now be done with dialog.close(viewModel, returnValue). If you need to customize the MessageBox, you can access it via dialog.MessageBox. It's view now uses text bindings instead of html bindings for better security. The dialog's default context has also been updated to take advantage of the new compositionComplete event so that sizing/position of the dialog occurs after all internal compositions are complete.
· The router has been completely re-written. It no longer has any dependencies outside of Durandal's core dependencies. (No more SammyJS) The router is built on top of a new history module which encapsulates the low-level history manipulation. This was done so that developers who have unique routing requirements can dispense with Durandal's router but not have to also re-write the history portion of the system. The new router adds a new router binding handler, child routers, better deep linking support, many bug fixes, support for not only parameterized routes, but also splats, optional parameters and query strings. It also has a better mechanism for handling unknown routes, default routes and conventional routing. The router also publishes events related to its activity and sports a simple, fluent configuration interface.
· The viewModel module was renamed to "activator" and its activator function was renamed to "create." Passing an array as activationData now results in activate being called with one argument for each array element.
· The viewEngine had some refactoring to expose parseMarkup and processMarkup. We also added ensureSingleElement and createFallbackView.
· New composition lifecycle. Without an activator: activate, beforeBind, afterBind, attachedToParent (renamed from viewAttached), compositionComplete, detachedFromDocument. With an activator: canActivate, activate, beforeBind, afterBind, attachedToParent, compositionComplete, canDeactivate, deactivate, detachedFromDocument. The compositionComplete event fires after the entire composition that the current view model is a part of is completely finished and all nodes are in the document. This event bubbles, starting by notifying child view models first, then parents. The detachedFromDocument event fires whenever the modules corresponding view is removed from the DOM. Composition now supports inline views by setting mode:'inline' on the binding and supplying the view as a child element. Composition now supports templated parts by setting mode:'templated' and supplying the part overrides as child elements. Composition now supports activationData which will be passed to the module's activate function.
· Fixed bug with widget part overrides that contain widgets with part overrides. Easier mapping of widgets via new widget apis: mapKindToModuleId/convertKindToModulePath and mapKindToViewId/convertKindToViewPath. Widgets are now almost entirely built on composition so the standard composition lifecycle applies. Widgets are now composed of a view.html and a viewmodel.js (not controller.js). Settings are no longer passed to the constructor, but into the activate function.
Via: Durandal 2.0.0
0 Comment:
Post a Comment