home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
OS/2 Shareware BBS: 10 Tools
/
10-Tools.zip
/
opendc12.zip
/
SG244883.ZIP
/
2.1
< prev
next >
Wrap
Text File
|
2001-01-27
|
9KB
|
197 lines
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<HTML>
<HEAD>
<base href="http://publib.boulder.ibm.com:80/cgi-bin/bookmgr/BOOKS/EZ30OZ00/2.1">
<title>
2.1 "OS/2 WARP and OpenDoc"
via IBM BookManager BookServer
</title>
</head>
<body background="/bookmgr/backdrop.gif">
<banner><br>
<a href="../../library"><img src="/bookmgr/libicon2.gif" border=0 alt="[Library]"></a>
<a href="CONTENTS#2.1"><img src="/bookmgr/contents.gif" border=0 alt="[Contents]"></a>
<img src="/bookmgr/drevs.gif" border=0 alt="[Revisions]">
<a href="2.0"><img src="/bookmgr/prev.gif" border=0 alt="[Prev Topic]"></a>
<a href="2.2"><img src="/bookmgr/next.gif" border=0 alt="[Next Topic]"></a>
<a href="../../search?book=EZ30OZ00"><img src="/bookmgr/search.gif" border=0 alt="[Search]" ></a>
<img src="/bookmgr/dslist.gif" border=0 alt="[Search Results]">
<img src="/bookmgr/dsprev.gif" border=0 alt="[Prev Topic Match]">
<img src="/bookmgr/dsnext.gif" border=0 alt="[Next Topic Match]">
<img src="/bookmgr/dnotes.gif" border=0 alt="[Notes]">
<img src="/bookmgr/dlnotes.gif" border=0 alt="[List Notes]">
<a href="../../print?book=EZ30OZ00"><img src="/bookmgr/print.gif" border=0 alt="[Print]"></a>
<a href="../../download/EZ30OZ00.boo"><img src="/bookmgr/download.gif" border=0 alt="[Download]" ></a>
<a href="../../help/book"><img src="/bookmgr/help.gif" border=0 alt="[Help]"></a>
<hr>
<a name="HDR4610DAR"><H2> 2.1 Architectural Overview</H2></a>
</banner>
<pre width="80">
OpenDoc is a collection of related interfaces that enable the
interoperability of components in a platform-independent way. As it is
shown in <a href="#FIG4610D01">Figure 5</a>, there are different kinds of interfaces OpenDoc must
take care of.
<p>
Think about a business graph component that is dragged into a text part.
<p>
The following considerations must be covered by an architecture to enable
that different components developed by different vendors, can
interoperate:
<p>
<a name="FIG4610D01"><hr>
</a>
<p>
<p>
<a href="picture-5?mode=zoom"><img src="/bookmgr/pictures/EZ30OZ00.P5.GIF" alt="PICTURE 5"></a>
<p>
<p>
<hr>
Figure 5. What a Component Architecture Must Address
<p>
<p>
1. Compound Document Services dealing with document-wide services:
<p>
░ Text and graphics are two different types of components with
different types of data. There is a common set of commands such
as printing where all components involved in a document must
cooperate and react in a homogenous way.
<p>
░ Both the text and the graphic components, have to interoperate
when the document is edited. They must share common resources.
Only one component, for example the text component, can be edited
at a time. This component is active and has the focus; that means
it is the addressee of all user interface actions. All keyboard
strokes or menu actions must be routed to the component that is
edited.
<p>
░ If the focus is changing because the graphics component is going
to be edited, the text component that is already active has to
clear its resources before it gives control to the other part. The
graphic part which receives control in turn should modify any
actions specific items, for example the menu items, to the graphic
component.
<p>
░ If a document is sent to other people, these people must be able
to work or at least be able to view the document even if they do
not have the same set of part handlers available on their machine.
<p>
2. Component Services covering interfaces between components.
<p>
░ A component may embed other components or not. A text component
should be able to embed other components.
░ The embedding component, also called a container, must be able to
communicate somehow with the embedded component to get some
information and to negotiate about a common layout.
░ A text component would usually want to react in different ways if
the embedded component is from the same type as the embedding
component. If a text component is dragged into a text container,
the text should probably be included in the text of the containing
part and not become a separate part.
░ The same decisions must be made if a component is embedded by
cut and paste. If the graphic component is pasted into a text
component, the text part should include the graphic as a separate
component, which must be handled by an appropriate part handler.
░ The architecture has to define a common interface related to the
document layout. If the graphic component is dropped to the text
component, both components have to agree upon the space requests
the component dropped has.
<p>
3. Storage System.
<p>
░ The Storage System must be standardized. When the compound
document is saved, different data types involved in a document
must be stored in a file.
<p>
░ A document stored in a file with different data types must
associate the appropriate part handler to the data, when the file
is opened.
<p>
░ If different people work on one document at the same time in a
network, there must be a mechanism to prevent changes made by one
person being destroyed if the document is saved by another person
at the same time.
<p>
4. Data Transfer between components in OpenDoc. This is part of the
storage system.
<p>
░ Data transfer between components may be done with drag and drop,
or clipboard actions such as cut/paste.
<p>
░ The graphic component may be pasted as a link to the text
component with a data source even on another machine. Linking
must be standardized by an component architecture.
<p>
5. Scripting.
<p>
░ Components have to be customizable and usable directly from other
components or applications.
<p>
░ There must be a uniform way to customize components with a script
language instead of the application-specific script dialects used
today.
<p>
6. Object Model.
<p>
░ If a newer release of the graphic component becomes available, the
part has to be updated without any dependencies to other
components.
<p>
░ They need to have a standardized binary interface to access the
components and enable plug and play behavior.
<p>
<p>
The technologies addressed by OpenDoc are structured in the following four
areas as shown in <a href="#FIG4610D39">Figure 6</a>:
<p>
░ How to visualize components defined by the compound document services
and the component services of OpenDoc
<p>
░ How to store and share components defined by the storage system
<p>
░ How to use components defined by the scripting architecture
<p>
░ How to access components defined by the underlying object model
<p>
<p>
<a name="FIG4610D39"><hr>
</a>
<p>
<p>
<a href="picture-6?mode=zoom"><img src="/bookmgr/pictures/EZ30OZ00.P6.GIF" alt="PICTURE 6"></a>
<p>
<p>
<hr>
Figure 6. OpenDoc Technologies
<p>
<p>
These areas are structured by the OpenDoc architecture as shown in
<a href="#FIG4610D04">Figure 7</a>.
<p>
<a name="FIG4610D04"><hr>
</a>
<p>
<p>
<a href="picture-7?mode=zoom"><img src="/bookmgr/pictures/EZ30OZ00.P7.GIF" alt="PICTURE 7"></a>
<p>
<p>
<hr>
Figure 7. OpenDoc Architecture
<p>
The base of the architecture used by all other pieces is the object model
defined by the OpenDoc Object Management Services. On top of the Object
Management Services there is the Opendoc Storage System, used by the
components to store their content. The services needed by the components
are defined in the OpenDoc Component Services. Services needed by the
hole document are defined in the OpenDoc Compound Document Services.
</pre>
</pre>
<hr>
<br><a href="2.0"><img src="/bookmgr/prev.gif" border=0 alt="[Prev Topic]"></a>
<a href="2.2"><img src="/bookmgr/next.gif" border=0 alt="[Next Topic]"></a>
<cite> ⌐ Copyright IBM Corp. 1996</cite>
<HR><p><h6><a href="/cgi-bin/bookmgr/library">IBM BookManager« BookServer</a> Copyright 1989, 1999<a href="http://www.ibm.com/"> IBM</a> Corporation. All rights reserved.</h6><p>
</BODY></HTML>