Difference between revisions of "FR/Documentation/BASIC Guide/OfficeDev/Using the Dispatch Framework"

From Apache OpenOffice Wiki
Jump to: navigation, search
(Created page with "{{DISPLAYTITLE:Utilisation du dispatcher}} {{Documentation/Note|'''Une traduction du texte est la bienvenue.'''}} The component framework with the Frame-Controller-Model par...")
 
 
Line 1: Line 1:
 
{{DISPLAYTITLE:Utilisation du dispatcher}}
 
{{DISPLAYTITLE:Utilisation du dispatcher}}
  
{{Documentation/Note|'''Une traduction du texte est la bienvenue.'''}}
+
{{Note|'''Une traduction du texte est la bienvenue.'''}}
  
 
The component framework with the Frame-Controller-Model paradigm builds the skeleton of the global object structure. Other frameworks are defined that enrich the communication between an office component and the desktop environment. Usually they start at a frame object for the frame anchors an office component in the desktop environment.
 
The component framework with the Frame-Controller-Model paradigm builds the skeleton of the global object structure. Other frameworks are defined that enrich the communication between an office component and the desktop environment. Usually they start at a frame object for the frame anchors an office component in the desktop environment.

Latest revision as of 14:33, 7 July 2018


Documentation note.png Une traduction du texte est la bienvenue.

The component framework with the Frame-Controller-Model paradigm builds the skeleton of the global object structure. Other frameworks are defined that enrich the communication between an office component and the desktop environment. Usually they start at a frame object for the frame anchors an office component in the desktop environment.

One framework is the dispatch framework. Its main purpose is to define interfaces for a generic communication between an office component and a user interface. This communication process handles requests for command executions and gives information about the various attributes of an office component. Generic means that the user interface does not have to know all the interfaces supported by the office component. The user interface sends messages to the office component and receives notifications.The messages use a simple format. The entire negotiation about supported commands and parameters can happen at runtime, while an application using the specialized interfaces of the component is bound to these interfaces at compile time. This generic approach is achieved by looking at an office component differently, not as objects with method-based interfaces, but as slot machines that take standardized command tokens.

We have discussed the differences between the different document types. The common functionality covers the generic features, that is, an office component is considered to be the entirety of its controller, its model and many document-specific interfaces. To implement a user interface for a component, it would be closely bound to the component and its specialized interfaces. If different components use different interfaces and methods for their implementations, similar functions cannot be visualized by the same user interface implementation. For instance, an action like Edit – Select All leads to different interface calls depending on the document type it is sent to. From a user interface perspective, it would be better to define abstract descriptions of the actions to be performed and let the components decide how to handle these actions, or not to handle . These abstract descriptions and how to handle them is specified in the dispatch framework.

Content on this page is licensed under the Public Documentation License (PDL).



Personal tools