Home

Language

Framework

Is Not

Principles of HybridJava Technology Component Model

1. The MVC paradigm

Web application components are reusable presentation layer modules that follow the MVC paradigm. So, each component may have its own View, Controller, and may be connected to a relevant part of the Model.

2. The One Touch principle

Using a component to build a page or another component must be as simple as using an HTML tag, and must not require any programming or configuration.

3. Independence

A page (or a containing component) doesn’t need to know anything about the contained component, and vice versa.

4. Session Scope Persistence

The framework has to keep the state of each component until the session expires. This behavior should not depend on the current page shown or on component’s actual visibility on its page.

5. In-page Reusability

A component may be used in a page (or containing component) more than once. For each use the framework must support an independent state.

6. Inter-page Sharing

A component may be declared as shared between several pages. Then, only one instance should be created by the framework for all the Views of that component.

7. Dispatching of Information

Framework should pass information about user actions (in particular about submit) to appropriate component instances. This should not require any additional programming, configuration or assigning of IDs to the components.

8. Inter-Component Communication

At the View phase a component/page should be able to pass information to contained components via widget parameters. At the Controller phase the framework API should support communication between a component and containing component/page.

Note that site developer works only within green areas. All the rest is already implemented in the framework. This way  no additional programming or configuration are necessary to use components. Just use the markup.

 

Model Implementation Details

Pages

Let us consider a hypothetical page PageName. The View of this page is coded in PageName.page file in HybridJava language. Each page has a corresponding page state class PageName_PS. The framework keeps instances of page state classes in the session, so all instance data members of a page state class are session-persistent. The $handlePage method of PageName_PS class is called by the framework when an HTTP request addressed to this page arrives. 

HybridJava Compiler introspects the page state class, parses the page View file and generates class PageName_P (presentation class). This generated class contains method $render which, when executed by framework, provides HTML output sent to the client. Presentation class is generated as derived from the page state class, so all the non-private members and methods of the latter are directly accessible in the presentation class.

Widgets and Components

Let us consider a widget WidgetName. The View of this widget is coded in WidgetName.widget file in HybridJava language. A component is a widget View, associated (by name) with class WidgetName_WS (widget state class a.k.a. component state class). The framework keeps instances of component state classes in the session, so all instance data members of a widget state class are session-persistent. The $handleWidget method of this class is called by the framework whenever an HTTP request addressed to the page arrives, but before the $handlePage method is called. The $handleWidget method of a component is called by the framework before $handleWidget of containing component.

HybridJava Compiler introspects the component state class, parses the component View file, and generates corresponding Java code as one or several parts of the $render method (mentioned above) of the page presentation class, so all page state data is directly accessible in the widget View code. Component state class data is also accessible in the component View code.

For pure View components (when components state class is not defined) no instances are created, so such components are truly lightweight. No tree of components is built at the runtime.

All page and component presentation data is stored in a single copy accessible both from View code and Controller code. Thus, there is no need to use JavaBeans, or to deal with data synchronization.

Dispatching

The framework cares about dispatching information coded in HTTP request parameters to appropriate component handlers or to the page handler. The information about submit action of the user is directed to the appropriate component handler if the submit was initiated from that component’s View. This works even under multiple loops and recursion.

Component handlers have to extract data from HTTP parameters using method $getParam. This method is similar to getParameter method of ServletRequest, except that only values originating from the View of the given component instance are accessible.

Handlers communicate to business layer and change the component and page state data. Redirection is not used to move to the next page. After the call to $handlePage method the framework calls the $render method of the next page to be shown.

API

The JavaDoc of the framework API is available here. HybridJava Framework API is wrapped around J2EE Servlet API and, compared to the latter, operates on higher level entities: application, pages, and components, though request, response, and session are still available.