This guide describes the process of developing an Expresso application. Although there are many different ways to use Expresso's components, the steps described here should provide your best results.

Developing an Expresso Application consists of the following general steps:

An Expresso application consists normally of a group of Database Objects (embodying the Model and persistence of the application), See the section on Database Objects for more information about Database Objects. Controller objects (providing the Controller aspects of the MVC architecture, and encapsulating all interaction with users), Job objects (handling all longer tasks and "background" jobs), and a single Schema object to tie them all together. At this point the application can be tested, using the default "view handlers".

Then the "view" of the application is created, using one of the several different UI technologies available - for example, JSP pages with Struts and the extended JSP tag library, or XML/XSL stylesheets.

Of course, the application can have many other objects that don't fall into these categories, but these are the main classes of objects that Expresso is concerned with and can help with. Please see the specific documentation in the EDG for each of these kinds of objects for where and how they can best be used.

Typically an Expresso application resides in a single top-level package, with a number of sub-packages. For example, if you are creating a membership management application, you might call the package com.yourcompanyname.members. Within the base package are usually the following packages:

Of course the application may require other packages, but these are the basics.

The Schema object for the application allows the entire application to be referenced by Expresso. This then allows Expresso to administer the application's security and other administration automatically when the Schema object is registered with Expresso (see Expresso's "Application" page for details on registering the Schema object with Expresso)

Usually you would create the Schema object in the "root" package for the application.

The easiest way to create your own Schema object is to copy an existing Schema class, such as the one included with eForum, which is in the com.jcorporate.eforum package, called "ForumSchema.java". You can then modify the following areas of the Schema to customize it for your application:

Database objects are normally created in the "dbobj" sub-package of the application. An Expresso application can use as many DB objects as required, and each should be listed in the Schema object for the application, so that the DBTool and DBCreate utilities in Expresso can create the required tables automatically for you when the application is first set up on a particular database. Database objects are designed to be the persistence layer of Expresso, and should take full advantage of the facilities provided by Expresso for them, such as caching, valid values, declarative referential integrity, and built-in security. See the page in the EDG on database objects to understand how to use these objects to their best advantage.

Controller objects should be used to encapsulate the logic of your application, especially any user-interaction required. The idea is to take advantage of things that are provided by the framework and not re-invent anything that is not required. You must design your user-interface in a presentation-independent way, thinking in terms of abstract inputs and outputs, to take best advantage of Controller objects. This allows you to take advantage of the GUI-independent user-interface abilities in Expresso, easily modifying the "view" of your application even once the logic is completed.

The controller chapter is dedicated to explaining the details of Controller objects can help you create and test your Controllers easily.

Job objects can be created and used for any task that can run independent of the user - e.g. longer tasks that do not require user interaction, or tasks that require extensive processing of databases or other data sources and might take some time. Typically a Job object is designed to send some kind of notification of it's completion to the originating user - the methods built into the Job object make this easy to do.

The page giving details of the Job object can help you create and deploy your Jobs effectively.