Difference between revisions of "SFX2 Refactoring"
| Line 5: | Line 5: | ||
For a better modularity we would like to remove sfx2 from the "model" implementation: | For a better modularity we would like to remove sfx2 from the "model" implementation: | ||
| − | + | {| class="prettytable" | |
| + | | [[Image:sfx2-old.png|thumb|383px|left|What we currently have]] | ||
| + | | | ||
| + | | [[Image:sfx2-new.png|thumb|383px|left|What we would like to have]] | ||
| + | |} | ||
| − | + | SfxObjectShell nowadays not only represents the dispatches for document based functionality but also the model implementation (from a UNO API point of view). The Controller is part of the dispatching process anyway. In the new architecture the dispatching part will be separated and its instantiation will be postponed until the dispatch framework asks for it. The model can be used without creating an SfxObjectShell and so without instantiating all the overhead of the sfx2 infrastructure. | |
| − | + | ||
| + | Some parts of this infrastructure will still be needed in the implementation of the model. These parts have to be identified and reimplemented in a way that it can be used as classes or services independent from sfx2. One example for this is the UNO service for tge DocumentInfo that currently is implemented the SfxDocumentInfo. This must be done the other way around: there will be a UNO service for the DocumentInfo that directly implements the API (mainly a PropertySet) and SfxDocumentInfo again will be a code wrapper that might be kept as long as code exists that still uses it. Converting this code to using the DocumentInfo service directly will make SfxDocumentInfo obsolete over time. | ||
==To Do== | ==To Do== | ||
| + | |||
| + | {| class="prettytable" border="1" | ||
| + | | Convert com.sun.star.document.DocumentInfo service | CWS basemodelrefactoring | Done | ||
| + | | Provide helper class/service for printing | CWS basemodelrefactoring | Done | ||
| + | |- | ||
| + | |} | ||
Revision as of 11:33, 14 September 2007
The problem
Though sfx2 no longer is the framework for everything it still is the backbone of the implementation of Writer, Calc, Draw/Impress and Math. sfx2 basically supports the MVC principle but it does not allow to decouple the parts as desired. The "template pattern" approach produces a very tight coupling of all involved classes and traditionally this was even enhanced by the application developers as they didn't try to limit the sfx2 influence as much as possible.
For a better modularity we would like to remove sfx2 from the "model" implementation:
 |
 |
SfxObjectShell nowadays not only represents the dispatches for document based functionality but also the model implementation (from a UNO API point of view). The Controller is part of the dispatching process anyway. In the new architecture the dispatching part will be separated and its instantiation will be postponed until the dispatch framework asks for it. The model can be used without creating an SfxObjectShell and so without instantiating all the overhead of the sfx2 infrastructure.
Some parts of this infrastructure will still be needed in the implementation of the model. These parts have to be identified and reimplemented in a way that it can be used as classes or services independent from sfx2. One example for this is the UNO service for tge DocumentInfo that currently is implemented the SfxDocumentInfo. This must be done the other way around: there will be a UNO service for the DocumentInfo that directly implements the API (mainly a PropertySet) and SfxDocumentInfo again will be a code wrapper that might be kept as long as code exists that still uses it. Converting this code to using the DocumentInfo service directly will make SfxDocumentInfo obsolete over time.
To Do
| CWS basemodelrefactoring | Done | CWS basemodelrefactoring | Done |
