Skip to content
Pierre Laborde edited this page Apr 9, 2022 · 10 revisions

Welcome to the Molecule wiki!

Introduction

Molecule is a component oriented framework for Pharo. His Component architecture approach provide an adapted structuration to graphic user interface (GUI) or another software application wich need Component features.

Molecule provide a way to describe a software application as a components group.

Molecule is a Light-weight implementation of the Corba Component Model (LCCM). It allows for the specification of components as in the Corba standard: provided and used services, produced and consumed events. However, Molecule components are only specified and instantiated locally. They are not exchanged nor shared through a standard object bus.

Molecule support completely transparent class augmentation into component (not necessary to add code manually), based on Traits.

Installation

Pharo 8, Pharo 9 and Pharo 10 :

Metacello new
   baseline: 'Molecule';
   repository: 'github://OpenSmock/Molecule';
   load.

Deprecated version of Molecule (1.1.x) for Pharo 6 and 7 is also available here.

Principles

This section briefly presents what is a Molecule component and how it is dynamically managed.

A Component and his Contract

Similarly to the LCCM, a component’s business contract is exposed through its component Type. The Type specifies what a component has to offer to others components (namely, provided services and produced events) and what that component requires from others components (namely, used services and consumed events).

Thus, the main role of the Type is to implement the services that the component provides (Provided Services) and that are callable by other components. Other components use this interface through their Used Services interface. Produced Events represent the receivable events interface of the component. Other components listen to this interface through their Consumed Events interface. They subscribe and unsubscribe to their event interface to start and stop receiving notifications. Parameters are used to control the component’s state. Parameters can only be used once at the component’s initialization. The light-weight CCM model does not define Parameters, but instead it allows direct access to public attributes. We introduced the Provided Parameters as an interface to explicitly define how the state of a component can be initialized. Other components use this interface through their Used Parameters interface.

A Molecule component definition is based on Traits. The Type, as well as the services, the events and the parameters parts are all defined as Traits. A Molecule component is an instance of a standard class which uses Molecule traits.

Two ways to implement a Component

In Molecule, we define the elements of a component's contract (services, events, parameters) as a set of Traits. A component Type aggregates theses traits, and is itself defined as a Trait. Molecule provides a dedicated Trait MolComponentImpl, which implements cross-cutting behavior shared by all components (e.g., components' life-cycle management). Implementing a component consists in defining a class that uses the MolComponentImpl Trait to obtain component shared behavior and uses a Type Trait (MolComponentType) implementing the component's business behavior.

The direct benefit of this approach is that it is possible for any existing class to become a component. This existing class is then turned as (or augmented as) a component, and becomes usable in a Molecule component application while remaining fully compatible with non-component applications.

Run-time management of Components

All components are managed by the ComponentManager object. It maintains the list of component instances currently alive in the system. It is currently handled as a singleton. The ComponentManager class implements an API to instantiate and to remove each component, to associate them, to connect events, etc. This API is used to manage each component life cycle programmatically.

Components lifecycle and states

The activity of a component depends on contextual constraints such as the availability of a resource, the physical state of hardware elements, etc. To manage consumed resources accordingly, the life-cycle of a component has four possible states: Initialized, Activated, Passivated and Removed.

After its initialization, a component can switch from an Activated state to a Passivated state and conversely. When the life-cycle of a component is over, then it switches to the Removed state.

Let us details each state of a component life-cycle.

  • When a component is switched to the Initialized state, it is configured through its provided parameters. If a component depends on another component through its interfaces (used services, consumed events or used parameters), these components are associated during this state.

  • The Activated state is the nominal state of a component. When a component is switched to this state, it subscribes to each consumed events that are produced by the components that have been associated with it during the Initialized state. After this subscription step, the component is able to receive and react accordingly to any of its consumed events.

  • When a component is paused, it switches to the Passivated state. Then, the component unsubscribes to its subscribed events and all its required resources are set in waiting mode. As an example, a hardware can be set in its sleeping mode, it can also be asked to free its Graphics Processing Unit memory. The idea behind this state is to avoid consuming resources if not needed, and to be able to switch back as quickly as possible to the Activated state.

  • The terminal state of a component is the Removed state. When a component switches to this state, all of it resources are released. The ComponentManager removes that component from its list of alive components.

Let us illustrate the use of these states with the example of a GUI window handled as a component. First, the window is instantiated by the component. Then the component state switches to Initialized. When the window is displayed on the desktop, the component’s state switches to Activated. When the window is reduced and its icon is stored into a task-bar, then the component switches to the Passivated state. As the window is only reduced, it can be re-opened very quickly. Finally, when the user closes the window. The component is first switched to the Passivated, then to the Removed state.

Tutorials section

Notes : This section is currently work in progress.

Create a new Molecule Component

External links

Learn more about CCM specifications.