The Akumina Frameworks - akumina/AkuminaTraining GitHub Wiki

The Akumina Frameworks provide for solutions around 2 key areas, Managing Data and Delivering or Presenting Data.

Managing Data

The AppManager framework is a provider hosted based Content Management system built for Office 365. The framework provides an abstraction layer connecting to 3rd party data sources (such as SharePoint and other data-centric technologies) and ships with pre-built Apps that connect to those data sources. This allows easy management of the data being stored in SharePoint and the other data sources. This framework also exposes an SDK allowing for the creation of custom Apps (for managing custom data systems) without needing to start from scratch every time and without needing to upgrade the core subsystem to expose new capabilities.

The App Manager Framework

The App Manager framework provides an SDK for the following areas:

  • Content, Management and Reporting Apps
    • Easily connect to any system with server side code
    • Create an 'App' with ease and focus on the use cases for your customer rather than how to setup and build a UI
  • Site Provisioning
    • TBD

Delivering or Presenting Data

The client-side Digital Workplace framework is designed to run inside Office 365/SharePoint in a SharePoint driven page and is predominantly used to create modern Intranet (or portal) experiences. The framework exposes a series of JavaScript widget components that allow for the presentation of SharePoint (and other) data to the Intranet consumer. Developers can extend/customize/repackage (and reuse) the out of the box widgets or build their own depending on the use case. Additionally, the framework exposes a data presentation layer that separates content from its presentation delivering capabilities not found in Office 365/SharePoint.

The ‘ViewManager’ uses a token like syntax for outputting dynamic data that is very easily understood by JavaScript developers, or a designer that may not write any JavaScript at all - essentially creating a Razor-like engine for client-side development.

Additionally, a built in targeting framework reads system and user properties from Office Graph and those are read into context objects that are subsequently available in JavaScript for developers to use.

Furthermore, multi-lingual capabilities go far beyond SharePoint variations, allowing the easy management and translation of content in any language.

The Digital Workplace JS framework

  • HTML Views – using handlebars/mustache

Separating content from presentation and allowing anyone with basic Javascript and HTML understanding to build a view. Handlebars is a well known templating engine that maps a Javascript model (object) to an HTML view without putting a tight dependency between the two. This means anyone who knows the Model being passed to the view can use it within their view. The model can be as simple as data coming directly from a Sharepoint list, or it can be a custom made model that maps data from another system. The idea is that the Model is what is passed to view, regardless of where it comes from.

This way the designer and ‘developer’ can work indepently against the same Model. The designer knows that the model will eventually be filled with actual data, and the developer will focus on filling that Model with data.

  • Custom Callbacks – for manipulating data bound to the view

In its basic form a callback is a well known function of Javascript, it allows a method to be passed in as an input parameter to another method. A callback in the DWP framework allows the developer to manipulate the raw Data Model and convert it to a UI Model. Think of the Data Model as being how you store the data, and the UI model as how you present the data.

  • Widgets – incorporate or package up your view / callbacks

  • UserContext mapping and Personalization

  • Page Lifecycle and Loader

The Page Life Cycle is a series of steps within the DWP Framework that are executed when a user navigates to a page. These steps execute every time a page is rendered (most of the calls are cached of course!) The reason this is an important part of the framework is to give the developer an understanding of when certain elements of the page will be ready, or loaded. Especially in a system where data is loaded asynchronously. It is also necessiary for providing feedback to the user that things are

happening on the page without waiting for all of the assets on the page to be loaded. Finally, it allows Akumina to provide functionality that will be inbetween when the page is rendered, and when the widgets are rendered.

  • Built-in Eventing

  • CAML Query builder