Difference between revisions of "SFX2 Refactoring"
(→The problem) |
(→The problem) |
||
| Line 3: | Line 3: | ||
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. | 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: | |
[[Image:sfx2-old.png|thumb|383px|left|What we currently have]] | [[Image:sfx2-old.png|thumb|383px|left|What we currently have]] | ||
| − | [[Image:sfx2-new.png|thumb|What we would like to have]] | + | [[Image:sfx2-new.png|thumb|383px|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. | ||
Revision as of 11:22, 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.
