Education ClassRoom/Previous Logs/framework part1
[11:28] <ericb2> mba_: why not present the begining today. Say a 30 min max presentation ?
[11:29] <mba_> I can do that. I will give a brief overview of what I could talk about.
[11:29] <ericb2> mba_: thank you :)
[11:29] <mba_> So, let's start.
[11:29] <FelixZ> mba_: Thanks
[11:30] <mba_> First of all, the Framework module is very privileged - because it is largely documented in our DevGuide.
[11:31] <mba_> If you look on the coarse diagram in our wiki ( http://wiki.services.openoffice.org/wiki/Framework ) you can see what the Framework basically is meant to do
[11:32] <mba_> It cares for the general managing of documents, task windows, the (high level) file handling, and more.
[11:32] <mba_> An important part of the Framework also is Embedding. But as I consider this to be "advanced", I will not go into details there.
[11:33] <mba_> If you are a macro developer or anybody else using OOo API you ususally will start with Framework API calls before you can do anything further.
[11:33] <mba_> Quite often this is the XDesktop::loadComponentFromURL method
[11:35] <mba_> This method belongs to an interface css.frame.XDesktop that not surprisingly is implemented by a service css.frame.Desktop, but also by all "frame" services (currently there is only one css.frame.Frame service but we always thought there could be more in the future).
[11:36] <mba_> The Desktop object does a lot more that I don't want to touch now, for a first reference I recommend to study the DevGuide ( http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/OfficeDev/Using_the_Desktop).
[11:38] * mod_ (n=mod@dslb-088-078-196-091.pools.arcor-ip.net) has joined #education.openoffice.org
[11:38] <mba_> loadComponentFromURL is expected to return a Component. The only interface that is mandatory for a compoent is the css.lang.XComponent interface that allows to control the components' life time.
[11:39] <mba_> BTW: I typed too fast - of course loadComponentFromURL belongs to css.frame.XComponentLoader.
[11:40] <mba_> What are these "components" in reality?
[11:40] <mba_> Or more exactly: what kinds of components can be loaded that way, usually into a frame?
[11:41] <mba_> Our idea was that these component could be "documents" (models) on the one extreme or simply windows on the other.
[11:42] <mba_> There is a third option that a simple view/controller pair without any model could be loaded into a frame and so the returned component might be a "Controller" object also.
[11:43] <mba_> Without going into the details too much here, the Desktop object and all the Frame objects form a hierarchy of frames that make up what we call the "Desktop Environment" that is described in the DevGuide also ( http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/OfficeDev/Desktop_Environment ).
[11:45] <mba_> All other parts of the Framework are implemented as additional services that are used inside the Desktop and Frame services.
[11:47] <mba_> There are several parts worth mentioning, the most important ones IMHO are the type detection and LoadEnvironment, the Dispatch Framework and the LayoutManager.
[11:49] <mba_> I don't want to talk about the TypeDetection and LoadEnvironment today as IMHO this is code isn't much interesting for new developers. It is quite "done" yet and it contains a lot of knowledge and "tricks" collected over the years.
[11:50] <mba_> The more interesting parts are the Dispatching and Layouting services as they usually offer a lot of opportunities to modify or extend them.
[11:51] <mba_> Understanding the Dispatch Framework ( http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/OfficeDev/Using_the_Dispatch_Framework ) is the key to understanding how the OOo UI can be extended or customized.
[11:52] <mba_> The idea we implemented here is that the UI of each loaded Component does not directly communicate with the outside world and that the UI of the outside world does not directly communicate with the component.
[11:54] <mba_> Every communication is routed through the frame. "Communication" means sending commands or exchanging status information for UI elements.
[11:55] <mba_> As the frame is the central part here every extension or customization can be applied at the frame - no need to plan for interactions with several, even yet-unknown components.
[11:56] <mba_> Examples for such things are that a simple communication file can be used to disable commands globally and - more important - the possibility to intercept command dispatching by registering DispatchInterceptors at the frame.
[11:58] <mba_> The Dispatch Framework is based on the idea that a command can be executed only if a Dispatch object can be found for it. So a UI element (e.g. a toolbar button) queries for such an object by asking the frame it is assigned to (how this assignment is done will be explained later).
