Everything you looked at in these first sections of this guide looks like a pretty easy and powerful way to use the language and the tools to put applications together. So what are the essential limitations of the kind of AppBuilder-generated procedure you built in this section?

Reusable components

For one thing, the sample procedure is not easily reusable. If you wanted to build a hundred table maintenance windows that all work much the same way (and that is a basic part of nearly any real business application), you have to set up an assembly line process to create them all. In the end you wind up with many procedures that create windows that all look and act more or less the same, but they would all be separate procedures requiring separate maintenance and testing. If you needed to make a change to your design, you need to make that change to all these separate procedures, and then retest and redeploy them. This would be a major headache and a source of unreliability in your application.

At the same time, you would undoubtedly want to extend the behavior of these windows far beyond what the simple Customers and Orders window does. You might want a real toolbar, for example, with standard icons and a menu. You might want the browse to perform a lot of additional tasks, such as sorting and column reordering and so forth. You might want other kinds of controls in the window, such as drop-down lists of valid values. If you coded each of these additional features for each window, you would have a tremendous amount of work on your hands.

So OpenEdge provides a set of standard components that do many of these things for you, which you can use to build many different kinds of application windows, as well as the back-end business logic those windows talk to. You can get to know these ABL SmartObjects™ in other OpenEdge documentation.

User interface independence

You might also like to make changes to the interface of your application, and even to change the client platform your application runs on, without having to rewrite your procedures. OpenEdge provides you with the tools to do this as well.

Distributed applications

Another limitation of your sample procedure is that is presumes that the client session running the interface has direct access to the database the application data is coming from. In a modern application, this is normally not the case. Whether you run your application on the Web with a browser-based UI, or simply provide global access to your database server from client machines running all over the country or all over the world, you will not be able to provide all of your users with the same kind of direct database connection that you may have had with older host-based or client/server applications. Later sections in this book introduce you to how to use ABL to construct business logic procedures that can run close to your database server using the Progress application server technology.

Dynamic programming

And perhaps most remarkable of all later you learn about ABL constructs that help you build dynamic procedures that can handle whole classes of behavior, so that one procedure can replace dozens or hundreds of older procedures that all did a similar kind of job for you. In this way, you learn how to write more effective and certainly more flexible and maintainable applications by writing far less code than you used to.

So there is a lot of exciting territory ahead. But before you get into some of the more advanced topics, such as how to work with the application server and how to write dynamic procedures, there are a lot of important and very powerful basics still to cover. The next section, for instance, goes into more depth on some of the block-structured principles that make ABL work and how you can use these blocks to retrieve and manage application data. Onward!