PRICING

HELP

BLOG

APPSTORE

COMPANY

LEGAL

LOGIN

This article will review the legacy Izyware frame architecture.

Introduction

Frames force an architectural pattern that will allow building UIs that work in a varitery of environments. The challenge with building hybrid applications is building the interface in such a way that would allow seamless integration with the existing UI. This typically calls for small footprint layered visual experiences. The frame architecture provides the tools for building such interfaces productive and maintainable.

The frames must enforce task-based and user-based navigation, and organize screen real estate more effectively by collating tasks, providing dedicated spaces for primary-task supporting information, and maintain general order and appropriate hierarchy among various elements on the screen.

The benefits to the end-user are primarily around standardization of look and feel which will provide consistency, predicability and ease of use. The engineering benefits are that this will enforce a reusable system of components that fulfill common layout and navigational requirements in a structured, consistent manner.

For a sample of reusable frames designed for different contexts (contentscript, popup, mobile, desktop, etc.) refer to components under the /frame repository. For illustration purposes, we will provide details on the elements for the stickydock frame.

Reference Implementations

popover

navable pieces (via. frame_setnav)

• views.body
• views.menu
• date

permanent pieces (via. frame_setkey)

• logomod
• bottompartmod

blog

navable pieces (via. frame_setnav)

• views.body
• views.menu
• date

permanent pieces (via. frame_setkey)

• logomod
• bottompartmod

companyportal1

navable pieces (via. frame_setnav)

• views.body
• views.menu

permanent pieces (via. frame_setkey)

• logomod
• bottompartmod

Frame Architecture

Benefits

UX

Make each group addressable* (i.e. via a URL) to allow a standard mechanism for describing features and accessing them either internally or externally.

• Provide a consistent user experience when transitioning from one feature to another. Examples include blurring, animations, sliding containers, zooming in/out.

Engineering

• Logical groupings and hierarchies for user faced features that are reusable in different context and at different depth in the hierarchy. An example would be the login flow. A good implementation would break down the login module into navigable pieces (login, sign up, forgot password, reset password, success, etc.) and would allow them to be either framed as part of the main navigation OR it can be framed on an overlay so that it wouldn't interfere with the main navigation. The current login implementation needs to be broken down into the 1) login components 2) a frame which would host the buttons, header, dialogbox, etc.
• The animations, blurring, etc. are difficult to implement. They need to be refactored at the frame level so that implementing frame parts is easier.

Provide a global* hub for each feature area to configure and communicate with other components.

• Make hierarchical configuration a lot easier

Highlevel Design

• a single component (mainnav) connecting to the navChange event on the browser. This can be exposed through the core (optional extension)
• different frame layer URLs are seperated by special characters and name of the layer the url belongs. This will allow for side by side as well as hierarchical. The mainnav will notify the corresponding frame when a change happens (seqs.onnavigate)
• at the component level when a transition chain is launched, it will bubble up through frames until the correct doTrainsition catches it.
• to support nested navigations, each frame thus should allow for creating child frames on the fly and with relative ease. That would be accomplished by routing the framenavxxxx commands through the parent higherarchy to the closests parent.

Implementation Guide

At the application root, the navmulti is created, which will define the root frame.

var modnav = modtask.ldmod('ui/w/shell/navmulti/multi');

modnav.setup(modtask);

// Optional

modnav.enableUrlMode();

// This is not related to NAV. It will just allow the application root to define customized TCs (frame_getnode, etc.)

modtask.modcontroller.registerCtrl(modtask);

Standard TC list defined by navmulti

• Navigation:

'framesetnav', 'frameaddnav', 'framenavretry', 'framenavigateback', 'frame_navigate'

• Current Navigated State:

'framegetparams', 'frame_getview'

• Frame Scoped Storage:

'framesetkey', 'framegetkey'

Navigation

Any part will be able to become a frame by:

['frameregister', partmodtask]

The framework uses inversion of control; The frame will need to define two sequences that it will get called on:

modtask.seqs.onsetnav

is called in response to setnav. Must reconfigure the ui navigational elements, and navigate to the appropriate UI element per modtask.modnav.

modtask.seqs.onnavigate

is called in response to navigation requests (url changes, frame_navigate, etc.). The frame will typically redraw the views based on the information provided by:

modtask.modnav.getViewFor(viewname)

It is important to seperate the registration of the frame from the definition of the UI and navigational elements and also be able to redefine the navigational items over and over throughout the frame lifecycle. A common use case is when the session status changes (login, logout, etc.) where the feature groups that are accessible should be restricted/allowed depending on the identity of the user. When the navitems are ready, the following command gets used:

['framesetnav', navitems, optionalframe]

Where

var navitems = [{

path: 'credential',

views: {

'body': modtask.ldmod("kernel\\path").rel("credential/list")

}

}, ...

The frame_setnav command can either come directly from the frame or anywhere in the system.

Current Navigated State

To create full link URL (i.e. for links):

['framegetparams', modtask]

Communication Between Current Viewes Whithin a Frame

frame_getview should be used for this purpose:

['frame_getview', 'body', modtask]

A typical implementation, like a save button on a header, will interact like this:

var getquery = {

"action": "get",

"newobj": {},

"success": false,

"reason": ""

}

push([

['frame_blur'],

['frame_getview', 'body', modtask],

function(push) {

push(["query", modtask.body, getquery, modtask, ""]);

},

function(push) {

if (getquery.success == false) {

return push(modtask.seqs.fail('form -- ' + getquery.reason));

}