• PRODUCT

    PRODUCT

  • PRICING
    PRICING

  • HELP
    HELP

  • BLOG
    BLOG

  • APPSTORE
    APPSTORE

  • COMPANY
    COMPANY

  • LEGAL
    LEGAL

  • LOGIN
    LOGIN

  • Workflow Automation

    Workflow Automation

  • AI Assisted Content Management System
    AI Assisted Content Management System

  • Analytics & Lead Generation
    Analytics & Lead Generation

  • Automation Projects
    Automation Projects

  • Browser Extension Apps
    Browser Extension Apps

  • Dashboard Theme Analysis: LN1
    Dashboard Theme Analysis: LN1

  • Data Exchange Automation Tools
    Data Exchange Automation Tools

  • Getting Started With Building Hybrid Apps
    Getting Started With Building Hybrid Apps

  • Izyware Hybrid UX Design Guidelines
    Izyware Hybrid UX Design Guidelines

  • Onboarding New Organizations Using Izyware
    Onboarding New Organizations Using Izyware

  • Quick Visualization and Monitoring
    Quick Visualization and Monitoring

  • Unified Metrics Stream Pipeline
    Unified Metrics Stream Pipeline

  • Legacy Features and Backward Compatibility
    Legacy Features and Backward Compatibility

  • How does the legacy frame architecture work
    How does the legacy frame architecture work

  • Izyware Legacy UI Circus Engine
    Izyware Legacy UI Circus Engine

  • Case Studies and Knowledge Center
    Case Studies and Knowledge Center

  • Angular and React Embedding Guide
    Angular and React Embedding Guide

  • Build and deploy a content distribution app in less than five minutes: Part II
    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 CSS Preprocessors SASS vs LESS vs STYLUS

  • Comparison of node.js test frameworks and utilities: lab, chai, sinon
    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
    Manage and automate your day to day business tools using IzyCloud Tasks: Part I

  • MySql Performance Optimization
    MySql Performance Optimization

  • Onboarding Tutorial: Creating & publishing an app
    Onboarding Tutorial: Creating & publishing an app

  • Rebranding and Customizing Websites
    Rebranding and Customizing Websites

  • Using IzyCloud on Android: IzyCloud Query App
    Using IzyCloud on Android: IzyCloud Query App

  • Technical Resources
    Technical Resources

  • .NET SDKCore IzyWare
    .NET SDKCore IzyWare

  • av-stream README
    av-stream README

  • ElasticSearch IzyWare Data Console Feature
    ElasticSearch IzyWare Data Console Feature

  • End To End Testing
    End To End Testing

  • End To End Testing, Part II
    End To End Testing, Part II

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

  • izy-circus README
    izy-circus README

  • izy-idman-tools README
    izy-idman-tools README

  • izy-pop3 README
    izy-pop3 README

  • izy-proxy README
    izy-proxy README

  • izy-sync README
    izy-sync README

  • IzyIDE README
    IzyIDE README

  • izymodtask readme
    izymodtask readme

  • IzyShell readme
    IzyShell readme

  • ReKey Feature Package README for IzyWare SQL Console
    ReKey Feature Package README for IzyWare SQL Console

  • Single Sign-On (SSO) README
    Single Sign-On (SSO) README

  • Tasks Migration : V5 guidelines
    Tasks Migration : V5 guidelines

  • Users & Groups README
    Users & Groups README

  • V5 Migration : apps/pulse guidelines README
    V5 Migration : apps/pulse guidelines README

  • Container Orchestration
    Container Orchestration

  • Izy Kubernetes Internal Networking Troubleshooting
    Izy Kubernetes Internal Networking Troubleshooting

  • Application Hosting
    Application Hosting

  • Content Publisher
    Content Publisher

  • Domain Registration
    Domain Registration

  • Email Hosting
    Email Hosting

  • Izyware Browser Extension
    Izyware Browser Extension

  • Izyware Deployment Engine
    Izyware Deployment Engine

  • Izyware Session Management
    Izyware Session Management

  • Messaging System APIs and functionality
    Messaging System APIs and functionality

  • Single SignOn
    Single SignOn

  • Integration APIs
    Integration APIs

  • iOS SDK
    iOS SDK

  • Azure and .NET
    Azure and .NET

  • izy-devops
    izy-devops

  • << How does the legacy frame architecture work
    << How does the legacy frame architecture work

  • Case Studies and Knowledge Center >>
    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.