Difference between revisions of "Documentation/DevGuide/OfficeDev/Properties of a FrameLoader"

From Apache OpenOffice Wiki
Jump to: navigation, search
m
 
(11 intermediate revisions by 4 users not shown)
Line 4: Line 4:
 
|OfficeDevDocFilter=block
 
|OfficeDevDocFilter=block
 
|ShowPrevNext=block
 
|ShowPrevNext=block
−
|PrevPage=Documentation/DevGuide/OfficeDev/Properties of a Filter
+
|PrevPage=Documentation/DevGuide/OfficeDev/Filter Options
−
|NextPage=Documentation/DevGuide/OfficeDev/Necessary steps
+
|NextPage=Documentation/DevGuide/OfficeDev/Document_API_Filter_Development
 
}}
 
}}
−
{{DISPLAYTITLE:Properties of a FrameLoader}}
+
{{Documentation/DevGuideLanguages|Documentation/DevGuide/OfficeDev/{{SUBPAGENAME}}}}
−
{{PRODUCTNAME}} distinguishes asynchronous (<idl>com.sun.star.frame.FrameLoader</idl>) and synchronous (<idl>com.sun.star.frame.SynchronousFrameLoader</idl>) frame loader implementations, but the configuration does not recognize that. The interface is supported by the loader is detected at runtime , the synchronous interface being preferred. The following properties describe a loader:
+
{{DISPLAYTITLE:Properties of a FrameLoader}}
 +
{{AOo}} knows asynchronous (<idl>com.sun.star.frame.FrameLoader</idl>) and synchronous (<idl>com.sun.star.frame.SynchronousFrameLoader</idl>) frame loader implementations. They are not distinguished by the configuration data but detected at runtime, synchronous loaders are preferred.
 +
 
 +
When a document is loaded using a <code>loadComponentFromURL()</code> call, a frame loader will always be used to load the "component" (in most cases a document model) into a frame. If no frame is registered for the type to be loaded, the generic frame loader of {{AOo}} will be used that will proceed with selecting a filter and using it. Custom frame loaders are not obliged to use filters and can do anything else instead. An expected use case is when the component isn't a model but e.g. a controller or window object.
 +
 
 +
Every FrameLoader inside {{AOo}} is specified by the properties shown in the table below. These values are accessible at the service <idl>com.sun.star.frame.FrameLoaderFactory</idl> using the interface <idl>com.sun.star.container.XNameAccess</idl>. Write access is not available here. All types are addressed by their internal names. The property names are identical to the configuration property names.
  
 
{|border="1" cellpadding=4 style="border-collapse:collapse;"
 
{|border="1" cellpadding=4 style="border-collapse:collapse;"
Line 15: Line 20:
 
|-
 
|-
 
|<code>Name</code>  
 
|<code>Name</code>  
−
|string. This must be a valid UNO implementation name. It should be obvious that this field can not contain the service name, because this value must be unique. Otherwise {{PRODUCTNAME}} could not distinguish more than one registered entry, for there can be several implementations for a service name. This value is also an entry in the corresponding configuration list.  
+
|string. The internal name of the loader. This is only an API property, not a configuration property. In the configuration, this is the name of the configuration node containing all the other properties. To avoid name clashes with other node names it should follow the rules outlined for [[Documentation/DevGuide/Extensions/Extension_Identifiers | extension identifiers]].  
 
|-
 
|-
 
|<code>UIName</code>  
 
|<code>UIName</code>  
−
|string. Displays the loader at a localized user interface. You must assign a value for a language, thus supporting CJK versions. All Unicode characters are permitted.  
+
|string. User-friendly name of the type. It may be localized using the localization support of the configuration. All Unicode characters are permitted here. Currently, this UI name is not used in {{AOo}} itself, but it is available for e.g. extensions.
 
|-
 
|-
 
|<code>Types</code>  
 
|<code>Types</code>  
−
|sequence<string>. A list of type names recognized by this service You can also implement and register loader for groups of types.  
+
|sequence<string>. A list of internal type names that this service can handle.
 
|}
 
|}
−
 
−
The service <idl>com.sun.star.frame.FrameLoaderFactory</idl> makes this data available. It uses the same mechanism as the <idl>com.sun.star.document.FilterFactory</idl>, that is, an interface for data access, <idl>com.sun.star.container.XNameAccess</idl>, and another one for creation of such a FrameLoader, <idl>com.sun.star.lang.XMultiServiceFactory</idl>.
 
−
 
−
There are other properties than the properties described, for example, for the ContentHandler. They are not necessary for the environment of filters, or loading and saving documents, so they are not described. Additional information is found at [http://framework.openoffice.org/ http://framework.openoffice.org].
 
−
 
−
There is one entry in the configuration, used as a fallback if a registered item is not found, the generic FrameLoader. It is not necessary for an external developer to provide a frame loader to add support for an unknown document format to {{PRODUCTNAME}}. It is enough to register a new filter component that is used by this special loader in a generic manner.
 
  
 
{{PDL1}}
 
{{PDL1}}
  
 
[[Category:Documentation/Developer's Guide/Office Development]]
 
[[Category:Documentation/Developer's Guide/Office Development]]

Latest revision as of 14:48, 9 August 2021



Apache OpenOffice knows asynchronous (com.sun.star.frame.FrameLoader) and synchronous (com.sun.star.frame.SynchronousFrameLoader) frame loader implementations. They are not distinguished by the configuration data but detected at runtime, synchronous loaders are preferred.

When a document is loaded using a loadComponentFromURL() call, a frame loader will always be used to load the "component" (in most cases a document model) into a frame. If no frame is registered for the type to be loaded, the generic frame loader of Apache OpenOffice will be used that will proceed with selecting a filter and using it. Custom frame loaders are not obliged to use filters and can do anything else instead. An expected use case is when the component isn't a model but e.g. a controller or window object.

Every FrameLoader inside Apache OpenOffice is specified by the properties shown in the table below. These values are accessible at the service com.sun.star.frame.FrameLoaderFactory using the interface com.sun.star.container.XNameAccess. Write access is not available here. All types are addressed by their internal names. The property names are identical to the configuration property names.

Properties of a FrameLoader
Name string. The internal name of the loader. This is only an API property, not a configuration property. In the configuration, this is the name of the configuration node containing all the other properties. To avoid name clashes with other node names it should follow the rules outlined for extension identifiers.
UIName string. User-friendly name of the type. It may be localized using the localization support of the configuration. All Unicode characters are permitted here. Currently, this UI name is not used in Apache OpenOffice itself, but it is available for e.g. extensions.
Types sequence<string>. A list of internal type names that this service can handle.
Content on this page is licensed under the Public Documentation License (PDL).
Retrieved from "https://wiki.openoffice.org/w/index.php?title=Documentation/DevGuide/OfficeDev/Properties_of_a_FrameLoader&oldid=248659"
Personal tools
In other languages