Split Design Time And Run Time

Context

Applicability

Problem

Forces

Participants

Structure

Collaborations

Resulting Context

Consequences

Known Uses

Example

Implementation

Sample Code

Related Patterns

[Below is the original pattern and format used; currently we're morphing it to our standard form. -ed.]

Intent

Split the design-time (customizability) part of a component away from the run-time portion of the component so that both halves can be utilized when needed, but that only the runtime portion can be shipped when space is an issue, or when the component should not be customizable.

Motivation

This is a long story that begins in the dawn of the age of modern Smalltalk (say 1989?). When I was first getting into Smalltalk, the hottest new thing on the block was a young upstart named Smalltalk/V PM (Smalltalk/V for Presentation Manager, and yes, that means OS/2). It was super-sexy in that it was the first Smalltalk to offer real native widgets. It was great, it was wonderful, it...had no window-builder tool.

This presented a problem to those of us who wished to use it. We first tried to get along by building windows by hand in code, but that seemed too much like C programming to us :) So, in my first real project in Smalltalk, CharleneBenson and I set out to build a Window-builder tool for Smalltalk/V PM under the tutelage of SamAdams and BillFelton. We had never done such a thing, so we didn't know exactly how to approach the task. We flailed around a bit, and finally got something working once we discovered CharlenesMagicMethod. Our Window-builder (called Child's Play) used the native V/PM widgets within the canvas. We wrapped our widgets in a movement wrapper that would allow you to size and move it. To code their behavior we let the users write code within a pane that was automatically compiled into a block and attached to the callback methods for the widget.

It worked. It made great demos. Unfortunately, it was a dead end. You see, the way we "saved" our drawn windows so that they could be attached to code was that we filed them out in ObjectFiler format, and then had the application code read the runtime objects back in later when they were needed. One time I sat down to try and figure out how to generate code that looked like it was hand-coded from the widgets. It looked like it would involve some significant modifications to the source code of the V/PM widgets itself. I was not encouraged by this, and so I never did it. The problem was that that our "builder-time" representation was so deeply tied up with the runtime widget that they couldn't be cleanly separated. We couldn't have one without breaking the other.

Then about a year later I got a copy of a product called WindowBuilder from CooperAndPeters. It was a revelation. It had the same drag-and-drop kind of window-building Child's Play had, but it generated source code. I was enthralled and had to understand how they accomplished this wonder. After a few minutes I found the key to understanding their approach:

Their "drawn" widgets weren't real. There was a design-time representation and a separate run-time representation

This allowed them a great deal of freedom. They had a separate "spec" object that represented the attributes that a runtime widget would have. That spec was capable of both generating runtime code to represent it AND starting up the dialogs that edited the properties. They also had a SEPARATE widget that actually represented the thing on the screen.

Later, when I looked at the first version of the VisualWorks product from Parcplace, I saw the same pattern repeated. There was a "Spec" class that represented the design-time attributes separate from the runtime representation of the widget.

Now, this is accepted practice. The Java Beans specification has interfaces such as BeanInfo?, Customizer and PropertyEditor? that are provided specifically for Design-time functionality. Now multiple development tools can work off of the same beans.

Forces

• If components are domestic in nature (i.e., in-process) they cannot used remotely and must be downloaded if they don't already exist on the local machine.
• If the component assembler is using a visual development environment to design a user interface based on components, much of the design-time code used to access and store properties is not needed at runtime.
• If components are copied to the client at runtime for execution, long delays can frustrate the user.
• Creating two versions of a component - one that contains runtime functionality and one that contains runtime and design-time functionality - can be difficult to maintain and debug.

• Use this pattern when you are developing a client-side visual component that will be assembled with a graphical window or web page builder.
• This pattern doesn't really apply to server-side components.

• WindowBuilder from SmalltalkSystems?
• VisualWorks from ObjectShare, and
• JavaBeans all of these are described above.
• Developing ActiveX components with technologies related to Visual C++ allows you to separate design-time from runtime. MFC traditionally implemented ActiveX controls with full property page and persistence functionality (you had no choice). This part of the framework was developed before the onslaught of the Internet. Since then, ATL has emerged as a solution to developing ActiveX components. You can create lightweight ActiveX controls that don't include an ounce of MFC and have no inkling of property pages.

• This pattern is really an implementation of a bigger pattern called MetaModel. The same idea that occurs here also occurs in BobbyWoolf's and RalphJohnson's TypeObject pattern.

Sort of. You can apply this pattern when developing JavaBeans like you can when developing ActiveX controls. But I don't know if the JavaBeans "API" itself could be considered a known use. -- PhilipEskelin

If not, is it that components need to have some design-time representation separate from the packaged binary code of the component itself. Components might have a representation of their behaviour that can be mechanically analysed by a model checker, for example, so that deadlocks, liveness failures and so on can be detected before implementation is begun.

-- NatPryce

Taking into account the forces described by Philip, I believe the JavaBeans package provides a framework for resolving points 2 and 4. There are interfaces such as BeanInfo?, Customizer and PropertyEditor? that are provided specifically for the Design-time functionality.

Adding to Nat's second paragraph, IMO the idea of Design-time and runtime separation is so that packaged binary code can be analysed/customised by the component based developer.

-- StuartBarker

This page mirrored in ComponentDesignPatterns as of April 29, 2006