Echo Web Framework

Creating User Interface Components

One of the most significant advantages of developing with Echo is its capability to allow for real component and object oriented development of Web-based applications. This capability is obviously without benefit if it goes unrealized. Echo developers are highly encouraged to extend the built-in Echo components when creating applications. If, for instance, you are trying to draw a screen that consists of a container pane which contains a few content panes, then by all means feel free to create a class which extends ContainerPane and at initialization adds the child panes and their components to itself. Break your application up into components in a fashion that makes sense from a perspective of maintainability--the performance effects will be minimal.

As a for-instance, imagine that you are creating an application for human-resources types to use to maintain a company's database of employee records. A well-designed application is going to be built using a component-oriented approach. You might create components for each "screen" of the user interface, each of which extends an AbstractPane. An EmployeeListScreen might provide a list of employees who work for the company, and an EmployeePropertiesScreen might be created to display information about a particular employee when one is selected from that list. An EmployeeErrorDialog might extend Window and be popped-up when a user attempts to enter invalid information when updating an employee.

We're obviously not going to teach everyone how to be good object-oriented programmers in the course of the prior two paragraphs. Just remember that the real benefit of Echo is the ability to create applications that are built using maintainable and reusable components. It's important to take advantage of it.

Effectively Using the EchoInstance

An EchoInstance object is tasked with representing the state of a single application-instance for a single user. EchoInstance is an abstract class, and as such a concrete implementation must be provided by the application developer. It's often a good idea to take your EchoInstance implementation beyond meeting the basic requirements. This class serves as the heart of an application, and should be used for storing state information and managing the on-screen components of the user interface for a single user's instance.

Retrieving a reference to the EchoInstance

Any registered component has the ability to return the EchoInstance with which it associated. A component is said to be "registered" if it has been added to a component hierarchy that is part of a visible window. The EchoInstance is obtained by calling the component's getEchoInstance() method. This method will return null if the component is not registered. In order to retrieve state information from a concrete implementation of EchoInstance, the returned EchoInstance object must be cast to the type of the concrete version defined by the application.

Because general application state data is stored in the EchoInstance, obtaining a reference to the EchoInstance is often required. Thus it is somewhat unfortunate that during the invocation of a Component's constructor that, since the Component is not registered at this point, the EchoInstance is inaccessible. Echo provides a solution for this problem with the init() method of the Component class. init() will be invoked on a newly constructed component exactly one time when the component is first registered. It is therefore possible to move all of the constructor's functionality into the init() method and do set-up tasks within it.

Storing State Data

Application-wide state data is generally stored in instance variables within the EchoInstance. Concrete implementations should provide accessor and mutator methods to retrieve and update any application-defined state data. As an example, imagine an application which requires authentication in order to be used. In this case the EchoInstance might store the logged-in user id, his or her name, access level, and other information commonly required by the application about the user.

Managing the State of the User Interface

It often makes sense to add methods to your EchoInstance implementation that allow for managing the overall state of the application. If an application required authentication, for instance, it might make sense to add a "logout()" method to the EchoInstance. When invoked, it would cause the user's session to be terminated. As another example, take a case where an application's user interface is laid out as a hierarchy of navigable screens. A design option here might be to have a ScreenStack stored in the EchoInstance and provide methods to have it open new panes and close its presently displayed pane in response to user navigation actions.