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

Legacy Features and Backward Compatibility

How does the legacy frame architecture work

Izyware Legacy UI Circus Engine

Case Studies and Knowledge Center

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

accounts README

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

Tasks Migration : V5 guidelines

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

AWS SDK

Azure and .NET

<< End To End Testing, Part II

izy-circus README >>

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

ui/w/shell/navmulti is one of the fundamental components for the framework.

Todo

• delete all keys on frame_register (reset state to unknown)
• remove the getView because it is view agnostic
• consolidate the resolveAndLoadPackageFromFullName with kernel/path stuff
• generic frame communication, i.e. ['framenavigate', '../info/1', 'UniversalframeId']

* we current only support communicate to '..' which is still very good. We already have parent via '..' but we need to do generic.

* we need to be able to notify other frames in the system.

Functions

• Incrementally maps a URI to functional pieces with are configured via the URI. These pieces can be defined on the fly (via calling frame_register). Each piece is called a frame.

* Most common use case is for defining UI hierarchy and embedding apps so that each app can be inserted/removed from the hierarchy independent of the others.

* Also used for Machine Experience builder content generation

• for each frame, the local url ->

matches (serialized version from the url)

params (environment info such as fullPath, path, currentUrlMatchedAgainst, etc.)

• validation is not done by this. Instead whether the context is running in circus or UI calcValidationState is called to accomplish this. See the notes for apps/pulse/viewer/collection/slide.js
• This will only care about

* How frames are created/destroyed/updated as state changes

* nested and heierachial definition of URI schemes to frame components (calcNav, etc)

* Communication between these frames (frame_notify, etc.)

Pieces

differentiate between '.' and '.*/'

* info/itemId/children will not work without this

• improve the way current frame state is communicated and get rid of modnav concept

* the old system uses framegetnavparams / framegetparams / framegetstate

* the return modtask.params

* framegetkey also sets modtask._matches ({"list"","tagselection1,"offset":0,"limit":50})

* instead we will just use frame_getkey, 'framestate' and will have

fullPath: '/dashboard/list/542147/list'

path: '/tagselection/./offset/./limit/.',

params: '',

currentUrlMatchedAgainst: '',

matches: { "list"","tagselection1,"offset":0,"limit":50 },

kvs: {}, // same as matches

previous: {},

current: {},

next: {},

all: [],

currentIndex: 0

* choose names that are easier to use

* instead of referencing the modtask.modnav, make the thing available as keys

* this is important for the editor mode because we may recreate or renew the module but not neccessarily recreate the frame.

* have something for 'iteration' so that next/last implementations are super easy (check the info/adjust/view)

• Serialize/Deseriazlie a URI to internal states
• Implements the frame_navigate that does these things (pieces may need to be decoupled, etc.)

* Update the state

* Update the URL

* notify state change to the correct handler

• implement get/set key mechanism within a frame context to simplify sharing of stuff between frame children.

ChangeLog

different between '.' and '.*/' to allow handling children for 'info//markdown'. Otherwise the will be 123/markdown

• reuse frame on frame_register if already exists

* This is needed to make sure that interactive design is possible. Otherwise when people edit the frame it will get reset and all will be reuined.

• improved get/set key to accept collection

* this will make the code simpler and more readable

• add ability to notify parent frame and set outcome via frame_notify. This makes notifications easier and bubbling up notifications a lot faster.

* With this, we can do a 1 liner pass thru to the upper level

['frame_notify', 'outcome', '..']

* At the lower level we can do

['frame_notify', { succeess: true, ... }]

• added feature to specify target frame for frame_xxx ops.

* This will enable cross frame data exchange (e.g. apps/pulse/viewer/info/adjust).

• Using isolateNav to have the ability to enable/disable url mode at each level.

* Sometimes (for example for SxS scenarios) we want to decouple the view changes from the url. Currently, at the app top level we have

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

modnav.setup(modtask);

modnav.enableUrlMode();

which is global. The issues are when someone does 'frame_register', they get put into a hierarchy and from that point on all the url changes will run through them. Need to be able to isolate a frame when we do frame register.

• Implemented dotdot navigation up ['frame_navigate', '../info/1']
• Fixed the case where a path match without a slash would not get captured
• Added logging capabilities
• Moved stateToPath and uriMatches functionality from apps/pulse into the framework. the stateToPath is now accomplished by allowing the passing of a JSON object to frame_navigate.
• uriMatches handle uridecode/encode