Application Framework Laboratory

Contents: Motivation Ongoing Work Achievements Artifacts Try ApplFLab Conferences, Workshops, etc. Projects

General-purpose application building tools support the creation of domain frameworks and the GUI applications that operate on those frameworks. Usually, the palette of user interface components that comes with the user interface builder only contains general-purpose user interface components that interact with the application framework in a general way. Building applications targeted to the domain at hand requires writing a lot of of application logic. What we need is the ability to build our own user interface components that encapsulate all the necessary component logic, so that writing application logic is minimised. But general-purpose user interface builders are generally closed systems, the set of available user interface components cannot be extended.

Domain-specific application building tools support the creation of applications for a specific problem domain. They offer all the entities with which a domain expert is familiar, so that applications are built on the domain level instead of the user interface level. This is the strength as well as the weakness of domain-specific application building tools. Usually these tools are so domain-specific that it is almost impossible to deviate from the domain and application frameworks imposed by the application builder.

Component-oriented application building tools allow fast application development by linking predefined user interface components, but they do not rely on a domain framework and the set of user interface components can only be extended from outside the component-oriented environment.

ApplFLab's aim is to bring these three styles of application building closer together. It enables the user to create his own user interface components that can be reused like any other standard user interface component. In general, self-made user interface components are domain-specific. They contain all the necessary component logic. They only have to be linked with the domain model. This leads to a component-oriented application building style.

Very important is that the domain framework designer, the application designer and the component designer work in the same medium.

Currently, we are upgrading ApplFLab's capabilities to the requirements of a few last year students, and to our needs to build tools that support reuse contracts. One student uses ApplFLab to generate layouts of web pages, another is experimenting with components to build browsers. At this time we are specialising ApplFLab to build an OMT class diagram drawing tool.

Many of the enhancements from this work find their way back into the core of ApplFLab. Future versions thus benefit from the experiments performed today.

One of the major obstacles that prevent users to use ApplFLab is the lack of good documentation. Writing a manual is one of the top items on our to-do list.

• Metro simulation. ApplFLab has been used to build components for the domain of metro simulations. First, the domain-specific framework was developed. In this framework all relevant metro simulation objects were implemented. Second, low level components were built, such as platforms and tracks. Then these new domain-specific components were assembled into more complex components, such as stations (which have two platforms) and two-way tracks. Stations were specialised towards terminal stations and crossing stations that serve as stations for crossing metro lines. The metro components encapsulate all the behavior necessary to let metro trains run from one station to another across a track that connects the two stations. The result was a specialisation of the application builder (i.e. ApplFLab) towards an application builder for metro simulations. The user of the metro simulation application builder composes applications by painting metro components on a canvas and by connecting the components to each other through aspects (with the properties tool, as usual in VisualWorks). The user does not have to write a single line of code! Installing the application (installing the user interface and defining the aspects) is enough to run the simulation.
  Note that the application builder is merely used as an interface to instantiate the underlying domain-specific framework. This experiment gives a good feeling of the componentware style of application composition where the components fit into a domain-specific framework. Picture

• Teleshopping. Standard components were used to compose components that can be used to build teleshopping applications. Two stores were composed out of these domain-specific components: a CD store and a video store. With each CD in the domain a sound file is associated and each video object corresponds with a QuickTime movie. Special domain-specific components were developed with ApplFLab to play the sounds and the movies. Other components, such as a cash register, shelves, a shopping bag, and special buttons to move CDs and/or video tapes from the shelves into the shopping bag, were built to make the user interface look like a real store.
  This experiment showed that self-made components can not only be used on the canvas of a new application, but also on the pages of the properties tool for other components. A fine example is the commercial component. It is a component that shows commercials. The user of the teleshopping builder employs the properties tool to select which commercial should be played. On the pages of the properties tool for the commercial component a file selection component and a movie component were reused to implement the commercial selection process. The user can browse the file system to choose a commercial and he can view the chosen commercial in the properties tool.

• Web page layout. The goal of a student's training project was to design a layout for a web page on which different types of multimedia information can be placed. The idea was to separate the layout of a page from its content, so that web pages could be set up dynamically from information retrieved from a database. The student has extended ApplFLab's minimal capabilities to put groups of components on a canvas. He has built special groups for automatic layout of components. By dropping a component fetched from the palette onto the group, the component is added to the group and the group changes the layout of its components accordingly.
  This experiment showed that ApplFLab focused on the composition of disjoint components, while sometimes composition through containment is necessary. While application building was only concerned with dropping components side by side on a canvas, this experiment required component composition that supports part-whole relations. The result is that a "whole" can now be placed on a canvas before the "parts" are filled in. The user can now drag a "whole" from a palette and plug in "parts" afterwards.

• OMT class diagram drawing tool. We wanted a simple OMT class diagram drawing tool in Smalltalk. Instead of developing it from scratch, we have extended ApplFLab. Since ApplFLab's painter is a component, it can be reused and specialised like any other component. So we have specialised the painter to a painter that has knowledge of the items that are painted with it, such as class diagrams and association links. The association links are placed automatically when the user connects two class diagrams with a connector tool which is available on the palette next to the selection tool. On top of that we have provided ApplFLab with the ability to switch between conventional painting and running the application without launching it. As a result, the user can switch between painting class diagrams and filling them in without leaving the painter. This experiment, although not yet completed, has introduced connectors in ApplFLab's painter as a means to connect components, possibly through another component. This behavior holds a lot of promises, because connectors can be used to wire components together without programming, nor configuration through a properies tool. Connectors should have come in handy in the metro simulation experiment, where metro stations are connected through tracks by hand. Instead of wiring the stations and tracks together with the properties tool, we could connect two stations with a connector and the painter would place the track automatically. Picture

Implementation

This implementation supports:

• Creation of self-made user interface components
  • painting of its user interface
  • generation of its link with the domain model
  • painting of its properties tool's user interface
  • installation on a custom palette
• Reuse of self-made components
  • in applications
  • in properties tools for self-made components
• Extended support for linking to the domain model
  • specifying adaptors without traditional programming

Guided Tour of ApplFLab

Presentations

• ApplFLab was first presented at OOIS'94 (paper abstract).
• ApplFLab was presented to the Belgian Smalltalk User Group at their 12th meeting .

Demonstrations

• ECOOP'95 (demonstration abstract)
• EHCI'95 (demonstration abstract)
• OOPSLA'95 (demonstration abstract)

Tutorials

• ESUG Smalltalk Summer School 1996
  • Exercises in Postscript
  • Handouts in Postscript
  • Slides in PDF
  • Slides in Postscript