A Thought Experiment: Rationale

Previous: 2. ui GUI toolkit Up: Rationale Next: 4. Models

---

• 3.01 What is a presenter?
• 3.02 Presenters derived from ui composite classes
• 3.03 Presenters derived from ui widget classes

Without actually demonstrating the superiority of the OO style of coding, the two examples given in the previous page form the basis for thought experiments that suggest important advantages for the OO approach. These benefits remain to be realized as we proceed with our investigation, a prime candidate being the evolution of presenters.

3.01 What is a presenter?

The word present can be a noun, an adjective, or a verb. The noun presenter is derived from the verb meaning to show or display, i.e., a presenter is something that presents (shows or displays). The verb, however, is double-transitive requiring a direct object (the object that is presented) and implying an indirect object (an object to which the direct object is presented). When we use the word presenter then, we have to ask What is presented? and To whom or to what is it presented?

A presenter is part of the presentation layer, which we initially said mediates between the user-interface layer and the abstraction layer. It is tempting, therefore, to think of the presenter as presenting a model to a view. This is probably a misleading perspective, however. In the first place, not every presenter is required to have a model. What is presented to the view in this case? Secondly, it is the view, not the model itelf, that is shown or displayed. It is therefore more accurate to say that the view is what is presented, and apparently it is presented to the user.

But why do we need something else to present a view to the user anyway? Doesn't the view "present" itself? Well, in many GUI applications, that is exactly how it is done, and defining the views in those cases can be tedious at best. A presenter helps make the job easier by linking a view to its model, and more importantly, it helps take care of component naming, binding, layout and/or event-handling. One way to take advantage of the OO benefits hinted at above, therefore, is for a presenter to be derived from the ui view that it presents to the user.

3.02 Presenters derived from ui composite classes

The OO benefits related to component naming, binding and layout are obtained by sub-classing the ui composite classes (Panel and Frame). The evolution of such presenters will deal with the following issues:

1. the view base class (e.g. ui.Panel),
2. initial pass at composition (naming, binding, layout),
3. refactoring composition: the self.Add(...) method,
4. passing specific parameters from composite to components,
5. composition by subclassing the presenter class (e.g. pr.Panel),
6. separating assembly from other aspects of initialization,
7. generalizing the passing of parameters,
8. nesting presenters and using composite models.

This investigation is found in the Experimental Results section entitled Composite presenters.

3.03 Presenters derived from ui widget classes

The OO benefits related to event-handling are obtained by sub-classing the ui widget classes (TextWidget, Choice and Button). The evolution of such presenters will take the following steps:

1. selecting the view base class (widget),
2. defining component event handlers,
3. connecting events to their handlers,
4. passing parameters from presenter to event handlers,
5. refactoring the API for ease of event programming,
6. making the presenter into an observer (of a model),
7. (elaboration versus extension).

This investigation is found in the Experimental Results section entitled Scalar presenters.

A Thought Experiment: Rationale

Previous: 2. ui GUI toolkit Up: Rationale Next: 4. Models

---