Zebra apllication developer's guide




	NS MDF

Zebra apllication developer's guide

A Zebra application consists of four tiers: business logic (BL), user interface logic (UIL), user interface presentation (UIP) and client:

Business logic (BL): The Business logic tier consists of classes implementing business workflows and providing interfaces to business operations. The business logic classes are zebra zbasics (java classes generated by the zebra generator whose behavior is normally defined by a UML state diagram) and any other necessary Java classes (for example, jdbc driver classes or FL classes). In the above picture it has two subtiers: implementation and interface. The BL interface tier is a set of java interfaces implemented by some classes from the BL implementation tier and accessed via naming or via another BL interface and used by the UIL tier and external systems and applications. These interfaces can be considered as capabilities provided by a zebra application for the UIL tier and/or other applications and/or external systems.
User interface logic (UIL): The User interface logic tier consists of classes implementing screenflows and user data validation and calling necessary business operations on underlying business interfaces. User interface logic classes are zebra zbasics and zebra zforms. Zbasics are usually screen flow controllers; they define the conditions of form invoking and the sequence of their appearance on the screen. Zforms are user interface form controllers; each zform represents one user screen or its element (for example, a zform can represent an html page, and an html frameset can be represented by several zforms, one for each frame, etc.).
User interface presentation (UIP): The User interface presentation (UIP) tier consists of UI forms depending on the type of the user interface and controlled by zform beans. There is one-to-one correspondence between zforms and zform beans: each zform has one and only one zform bean that is created at the moment a zform is created. A zform bean has a set of attributes essential for both the UI logic and the UI presentation, in some sense it is an interface between them. A zform bean can be either registered in the UI presentation tier or not; a zform controls the process of registering and unregistering a zform bean. A not registered zform bean is visible to the user in no way; a registered one is represented by some UI form. The correspondence between form beans and UI forms is presentation dependent, but usually one or several UI forms are statically registered to represent some zform bean class (for example, JSPpresentation specifies one JSP page for each zform bean class). UI forms use zform bean attributes to change their own representation; user input is processed and results in changing zform beans’ attributes and/or sending events via zform beans to zforms.