Difference between revisions of "Framework/Article/Implementation of the Dispatch API In SFX2"
| Line 8: | Line 8: | ||
The basic idea is that the ''Controller'' (the component used by a document to participate in the dispatch process) is able to take any CommandURL it receives in a request for a Dispatch Object and compares it with the CommandURLs in the set of commands it supports. If a match can be achieved a Dispatch Object is returned. The SFX based components charge their common Controller base class (''SfxBaseController'') implementation with the task of implementing this job based on the old SFX framework.<br/> | The basic idea is that the ''Controller'' (the component used by a document to participate in the dispatch process) is able to take any CommandURL it receives in a request for a Dispatch Object and compares it with the CommandURLs in the set of commands it supports. If a match can be achieved a Dispatch Object is returned. The SFX based components charge their common Controller base class (''SfxBaseController'') implementation with the task of implementing this job based on the old SFX framework.<br/> | ||
| + | |||
| + | This old framework organized functionality in context that can be merged together and exposed to the outside world by a single point of contact. This contact point is an ''SfxDispatcher'' object that every ''SfxBaseController'' owns. The SfxDispatcher internally maitains a stack of objects, each representing a context. Examples for the contexts are "document, "view", "text", "table", "cell" etc. The complete stack of all contextual objects (all deriving from the common base class ''SfxShell'') available in a particular situation represents the function set applicable to the current selection or cursor position in a document. Context changes inside the documents editing window causes pushing and poping of shell objects to and from the stack. | ||
| + | |||
| + | This is how a typical stack in Writer looks: | ||
| + | |||
| + | * Text | ||
| + | * View | ||
| + | * Document | ||
| + | * Frame | ||
| + | * Module | ||
| + | * Application | ||
| + | |||
| + | The ''Frame'' and ''Application'' contexts are there for historical reasons, we are still in the process of moving their functionality to the framework where other ''DispatchProviders'' outside of the component take over. I omitted the "Form" context here because it's somewhat confusing. | ||
Revision as of 08:19, 22 December 2006
Implementation of the Dispatch API in SFX2
The Dispatch API as described in chapter 6.1.6 of the Developer's Guide is the backbone of our communication between "generic" UI elements and the document core implementations.
Traditionally SFX based components implemented this communication with a much older framework based on the so called slots and their organization into shells. While up to OpenOffice.org 1.1 our generic UI elements (menus, toolbars, etc.) still used the SFX based API directly to a large degree in OpenOffice.org 2.0 we changed this to using the Dispatch API exclusively, thus enabling us to share the UI components with other, not SFX based components. This paper describes how the old SFX implementation is matched to the DispatchProvider implementation that the component provides to the outside to make this happen.
The basic entity in the dispatch API is a command, and it's represented by a CommandURL. For simplifications we suppose that this CommandURL is a string (though the API transport it as a pre-parsed struct). All commands supported by our components have the form .uno:xxxxx for historical reasons, where xxxxx represents an internal command name.
The basic idea is that the Controller (the component used by a document to participate in the dispatch process) is able to take any CommandURL it receives in a request for a Dispatch Object and compares it with the CommandURLs in the set of commands it supports. If a match can be achieved a Dispatch Object is returned. The SFX based components charge their common Controller base class (SfxBaseController) implementation with the task of implementing this job based on the old SFX framework.
This old framework organized functionality in context that can be merged together and exposed to the outside world by a single point of contact. This contact point is an SfxDispatcher object that every SfxBaseController owns. The SfxDispatcher internally maitains a stack of objects, each representing a context. Examples for the contexts are "document, "view", "text", "table", "cell" etc. The complete stack of all contextual objects (all deriving from the common base class SfxShell) available in a particular situation represents the function set applicable to the current selection or cursor position in a document. Context changes inside the documents editing window causes pushing and poping of shell objects to and from the stack.
This is how a typical stack in Writer looks:
- Text
- View
- Document
- Frame
- Module
- Application
The Frame and Application contexts are there for historical reasons, we are still in the process of moving their functionality to the framework where other DispatchProviders outside of the component take over. I omitted the "Form" context here because it's somewhat confusing.
