PRICING

HELP

BLOG

APPSTORE

COMPANY

LEGAL

LOGIN

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.

Izyware Help Articles