Widget Provider

Widget Provider

the basic idea

In the surface of a new module, components are needed that have already been implemented in other modules. In order to avoid creating a largely identical InstantView code, elements of the surface description should be reused.

In the new window, for component 2, ready-made code from module A is used, component 3 uses an existing solution from module B

In the following we call the importing module Consumer, the modules with reusable components are called Provider modules.

Objective and delimitation to widget inheritance

• A consumer module can import from any number of provider modules.
  
• Consumer and provider are decoupled as far as possible. The subsequent use by consumer modules must not hinder the further development of the provider modules. Therefore, widget commands are restricted to their import context and widget commands executed from the imported provider widget cannot find widgets of the consumer by-name and vice versa.
  
• A provider tag + the tuple (window name, name of the component) form the interface between provider and consumer.
  A consumer never refers directly to a provider module. As in procedure providing, the provider tag is used to ask for a module that offers the corresponding component. (The code on the provider side is free for any kind of refactoring, e.g. to change the inheritance hierarchy)
  
• The InstantView code associated with the widgets will be imported! Not only the interface description should be reused, but also the logic already implemented in the provider module.
  The following three points refer to the possibilities with which the imported code can be seamlessly integrated into the consumer module.
  
• The consumer can overwrite and extend the reaction to events of the imported components.
  
• Variable Binding: Variable in the consumer code and variable in the imported code are bound together so that they reference the same value. The binding only applies to the import. It is possible to import the same component several times, but define different variable bindings. Variable binding is only available for variables in the module scope.
  
• Partial import: A larger component was designed in the Provider module, of which only a part is now to be imported.
  The problem: the imported code can also refer to widgets that were not imported.
  Statements that only modify the surface are ignored. If there are statements that read from a widget that was not imported, the import will not work and probably does not make sense logically.
  

InstantView instructions

Statement Import

How are events overwritten?

Statement ImportContext (Variable Binding)

Partial Import

FillWindow / DrainWindow / ClearWindow

an example

The application is the Consumer Module

and refers with the tag item to a provider

A component imported from a provider may itself contain imported components; widget-providing also works transitively.