PRICING

HELP

BLOG

APPSTORE

COMPANY

LEGAL

LOGIN

AI Assisted Content Management System

Analytics & Lead Generation

Automation Projects

Browser Extension Apps

Dashboard Theme Analysis: LN1

Data Exchange Automation Tools

Getting Started With Building Hybrid Apps

Izyware Hybrid UX Design Guidelines

Onboarding New Organizations Using Izyware

Legacy Features and Backward Compatibility

How does the legacy frame architecture work

Izyware Legacy UI Circus Engine

Case Studies and Knowledge Center

Angular and React Embedding Guide

Build and deploy a content distribution app in less than five minutes: Part II

Comparison of CSS Preprocessors SASS vs LESS vs STYLUS

Comparison of node.js test frameworks and utilities: lab, chai, sinon

Manage and automate your day to day business tools using IzyCloud Tasks: Part I

MySql Performance Optimization

Onboarding Tutorial: Creating & publishing an app

Rebranding and Customizing Websites

Using IzyCloud on Android: IzyCloud Query App

Technical Resources

.NET SDKCore IzyWare

ElasticSearch IzyWare Data Console Feature

End To End Testing

End To End Testing, Part II

frames and nav (ui/w/shell/navmulti) README

izy-circus README

izy-idman-tools README

izy-pop3 README

izy-proxy README

izy-sync README

IzyIDE README

IzyShell readme

ReKey Feature Package README for IzyWare SQL Console

Single Sign-On (SSO) README

Tasks Migration : V5 guidelines

Users & Groups README

V5 Migration : apps/pulse guidelines README

Container Orchestration

Izy Kubernetes Internal Networking Troubleshooting

Application Hosting

Content Publisher

Domain Registration

Email Hosting

Izyware Browser Extension

Izyware Deployment Engine

Izyware Session Management

Messaging System APIs and functionality

Single SignOn

Integration APIs

iOS SDK

AWS SDK

Azure and .NET

<< How does the legacy frame architecture work

Case Studies and Knowledge Center >>

Izyware Legacy UI Circus Engine

This article describes the legacy IzyCircus UI engine

Parts: Elastic Building Blocks

The recommended method for creating UI components is to use the Part notation:

{

css : 'color:red',

parts : 'text',

what : 'Hello'

}

This will remove the burden of creating components in HTML. Also since Parts can be defined using the DAD notation, interactive design and on demand tools will be available.

Each UI part can be broken down and partitioned into subparts. See the parts chapter for more info.

Each corresponding HTML element gets mapped to a part. In addition the part object will be instantiated in memory and can be manipulated independent of its HTML contents.

Transition Chains

Transition Chains (TCs) are the building blocks by which behavior is \programmed\.

Introduction

Transition Chains standardize the way by which \transitions\ in the application state (changes to the UI, computations, etc.) are defined. Some examples of transitions are:

• responding to \standard\ events such as user input, timer, ready.
• responding to custom defined events (usually triggered by other parts).
• doing things such as changing UI, running custom code, etc.

The most important feature of TCs are that:

• they are serially asyncronous (similar to node.async series) thus providing the elasticity and hot designability of the part.
• when acting on a UI part (refresh, remove, etc.), they support \automatic queueing\. This mechanism essentially removes the burden of worrying about DOM timing issues: if it comes across a transition on a part that is not yet rendered (ready), it will queue that transition and will perform it when the part becomes ready.
• they are associated with a \part context\ that makes the syntax easier to read and understand.

Syntax

A simple static transition chain may be defined as:

[

['t1', ...],

['t2', ...]

]

Each transition is an an array. The first element must be a string which is the name (method) of the transition. The other elements are optional.

Nesting and grouping is allowed, so:

[

['t1'],

[

['t2'],

['t3']

]

]

Is equivalent to:

[

['t1'],

['t2'],

['t3']

]

DAD notation is supported for each individual transition as well as the chain.

Running Transition Chains

Internally, a TC is run by:

controller.doChain(

part, // context part

transitionchain, // transitionchain

function(outcome) {} // callback [OPTIONAL]

);

The most common use case is:

modtask.modcontroller.doChain(

modtask,

[

['t1'],

....

]

);

Also, the \push\ transition that is used for cross scope communication uses the same method.

['push', 'eventname', destinationpart]

Implementing New Transitions

Anyone can extend and create new transitions. This feature allows for for global communication (building shells, etc). In addition, it is the best way to extend the functionality of the core platform. This is the recommended method for having \global\ services (i.e. expose it as an transition) as opposed to using global variables, because:

• it provide asyncronous access to services, allowing \on-demand\ retrieval
• it removes potential timing issues that would arise when access a global variable
• removes potential caching issues when it comes to consuming global services. i.e. consuming the node service's state will change when users log in and out. Having a cached node instance is going to lead all sorts of problems. Instead, the node instance should be grabbed by querying the frame via the frame_getnode transition
• it is more readable
• it will make debugging and logging extremely simple
• removes the coupling between components, thus allowing interchanability of services. The example is the shell session manager.

The Syntax is:

modtask.modcontroller.registerCtrl(handler_module);

This is commonly used for defining access to node. As an example:

modtask.modcontroller.registerCtrl(modtask);

...

modtask.doTransition = function(transition, callback) {

var params = transition.udt[1];

switch (transition.method) {

case "frame_getnode":

var accesstoken = modtask.ldmod('ui/w/shell/sessman/accesstoken_ck').get();

var node = modtask.ldmod('ui/node/direct').sp({

'accesstoken': accesstoken,

'dataservice': 'https://izyware.com/apps/izyware/',

'groupidobject': {

transportmodule: 'qry/transport/scrsrc'

}

}).sp('verbose', false);

params['node'] = node;

callback(transition);

return true;

break;

}

};

Dynamic Asynchronous Definition (DAD)

Parts and transitions can be defined using DAD.

Part Example

The following:

{

parts : 'text',

what : 'Hello World'

}

Is equivalent to:

function(push) {

push({

parts : 'text',

what : 'Hello World'

});

}

Transition Example

The following:

[

['t1'],

['t2']

]

Is equivalent to:

[

['t1'],

function(push) {

push(['t2']);

}

]

Flow

• the UI engine will start from an external environment by calling the rdr method:

modtask.ldmod('ui/core').rdr('uimodename');

• This will call \modcontroller.beginRender()\ which will iterate through the part and render it.