Difference between revisions of "Education ClassRoom/Previous Logs/framework part1"

Revision as of 10:19, 4 June 2008

[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).

[11:58] * mod_ (n=mod@dslb-088-078-196-091.pools.arcor-ip.net) has left #education.openoffice.org

[12:00] <mba_> The frame now can either handle the command itself (because it knows it and does not want to allow others to handle it or because this command is disabled by configuration), pass it to its component if it also imlements Dispatching) or scans the configuration whether there is another DispatchProvider object that can handle the command.

[12:00] <mba_> The last option is the base for the whole Extension infrastructure.

[12:02] <mba_> An extension usually registers DispatchProvider services for a group of Commands that start with the same prefix called "protocol" (thus these services are called ProtocolHandlers). So a Frame is able to dispatch commands to them and OTOH receive status information from them.

[12:03] <mba_> So it is understandable that UI elements or any code that wants to execute commands must be assigned to a frame. This assignment is done by passing the frame that carries the targetted component, either by a direct API call of as an initialization parameter.

[12:03] <mba_> For UI elements like toolbar buttons this happens inside the LayoutManager.

[12:04] <mba_> The LayoutManager (I will talk about it later) is always directly attached to a frame. Or the other way around: each frame has one.

[12:05] <mba_> The purpose of the LayoutManager is to organize panels, toolbars, docked windows etc. and resize the internal document window properly. It also uses some internal services to create UI elements like toolbars or the menu.

[12:06] <mba_> It is important to see that UI elements are very abstract on the LayoutManager level, they are just UNO servives with a small API. This e.g. enables the Framework to work with Windows and Mac menubars without changing a lot of code.

[12:07] <mba_> Everytime when UI elements are created, the Frame of the LayoutManager is passed to them so that UI elements know where to send command requests to or where to get status updates from. In fact usually the Frame is everything they know.

[12:08] <mba_> The Layout Manager itself and how it creates the OOo user interface is described at http://wiki.services.openoffice.org/wiki/Framework/Article/General_Architecture_Of_The_Framework_User_Interface_Implementation

[12:11] <mba_> So this is a very coarse overview of the main parts of the Framework. What do you think: should we start with going into details now, should we already ask and answer questions or should be give people a chance to read the log and the documentation I pointed to and the proceed in another session?

[12:12] <ericb2> mba_: is everything you explained located in framework (the module in OpenOffice.org source tree ) ?

[12:12] <ericb2> mba_: or are there other parts elsewhere ?

[12:12] <mba_> Yes - except parts of the TypeDetection

[12:12] <ericb2> mba_: thank you

[12:12] <mba_> The TypeDetection uses the FilterConfiguration that is part of the "Filter" module

[12:13] <ericb2> mba_: noticed :)

[12:13] <ericb2> mba_: from my side, what I learned is enough (a lot to read until the next part)

[12:14] <ericb2> mba_: what you explained is incredibly precise, and very usefull for the understanding of OpenOffice.org. I must admit it was a dark side for me

[12:15] * SaSaintete (n=bidule@ARennes-352-1-126-114.w86-203.abo.wanadoo.fr) has joined #education.openoffice.org

[12:15] <FelixZ> mba_: Is dispatching currently located in framework module too?

[12:15] <mba_> FelixZ: yes and no.

[12:16] <ericb2> mba_: well, I still have to read and learn, else I won't progress :)

[12:16] <FelixZ> mba_: I find /sfx2/source/control/dispatch.cxx, that's why I'm a little confused

[12:16] <mba_> Of course commands handled by the frame, the infrastructure for Interceptors and ProtocolHandlers and the DisableCommands handling are implemented in the Framework module

[12:17] <mba_> But as I said, the components inside the frame also may implement dispatching and they usually do

[12:17] <mba_> Most of our components are documents based on the sfx2

[12:17] <mba_> sfx2 is our old framework and in former times also contained a desktop, frames etc. but in a very highly-coupled, non-modular implementation

[12:18] <mba_> So we decided to reimplement our framework based solely on UNO interfaces and services

[12:18] <mba_> The sfx today "only" is the backbone of the dispatching implementation of the Controller objects of our documents.

[12:19] <mba_> You can read more about that at http://wiki.services.openoffice.org/wiki/Framework/Article/Implementation_of_the_Dispatch_API_In_SFX2

[12:19] <mba_> But this is very advanced stuff and I don't recommend to read that before having a solid understanding of the general dispatching