1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
|
/*************************************************************************
*
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* Copyright 2000, 2010 Oracle and/or its affiliates.
*
* OpenOffice.org - a multi-platform office productivity suite
*
* This file is part of OpenOffice.org.
*
* OpenOffice.org is free software: you can redistribute it and/or modify
* it under the terms of the GNU Lesser General Public License version 3
* only, as published by the Free Software Foundation.
*
* OpenOffice.org is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU Lesser General Public License version 3 for more details
* (a copy is included in the LICENSE file that accompanied this code).
*
* You should have received a copy of the GNU Lesser General Public License
* version 3 along with OpenOffice.org. If not, see
* <http://www.openoffice.org/license.html>
* for a copy of the LGPLv3 License.
*
************************************************************************/
#ifndef __com_sun_star_document_TypeDetection_idl__
#define __com_sun_star_document_TypeDetection_idl__
#ifndef __com_sun_star_document_XTypeDetection_idl__
#include <com/sun/star/document/XTypeDetection.idl>
#endif
#ifndef __com_sun_star_container_XNameContainer_idl__
#include <com/sun/star/container/XNameContainer.idl>
#endif
#ifndef __com_sun_star_container_XContainerQuery_idl__
#include <com/sun/star/container/XContainerQuery.idl>
#endif
#ifndef __com_sun_star_util_XFlushable_idl__
#include <com/sun/star/util/XFlushable.idl>
#endif
//=============================================================================
module com { module sun { module star { module document {
//=============================================================================
/** capsulate a type detection service and provide read/write access on it's configuration data.
<p>
It's possible to make a "flat" detection wich may use internal configuration
data only - or a "deep" detection which use special <type>ExtendedTypeDetection</type>
services to look into the document stream. Last mode can be supressed to perform the operation.
Of course the results can't be guaranteed then. (e.g. in case the extension was changed)
</p>
*/
published service TypeDetection
{
//-------------------------------------------------------------------------
/** can be used to make a flat or deep type detection.
<p>
Use this interface to get information about the type of the given resource.
Return value will be always an internal name of a registered document type.
It can be used may on other services (e.g. <type scope="com::sun::star::frame">FrameLoaderFactory</type>)
to do further things, which base on it (e.g. to load it into a frame).
</p>
*/
interface XTypeDetection;
//-------------------------------------------------------------------------
/** provides read access to the complete set of type configuration data.
<p>
Every container item is specified as a set of properties and will be
represented by a sequence< <type scope="com::sun::star::beans">PropertyValue</type> > structure.
Follow properties are supported:
(But note: not all of them must be present everytimes!)
<table border=1>
<tr>
<td><strong>Property Name</strong></td>
<td><strong>Value Type</strong></td>
<td><strong>Description</strong></td>
</tr>
<tr>
<td><em>Name</em></td>
<td>[string]</td>
<td>The internal name is the only value, which makes a container item unique.</td>
</tr>
<tr>
<td><em>UIName</em></td>
<td>[string]</td>
<td>It contains the localized name for this type for the current locale.</td>
</tr>
<tr>
<td><em>UINames</em></td>
<td>[sequence< string >]</td>
<td>It contains all available localized names for this type. The are organized
in pairs and represented as a structure of sequence< <type scope="com::sun::star::beans">PropertyValue</type> >.
The name of such property must be interpreted as locale; it's value as the localized
type name corresponding to this locale.</td>
</tr>
<tr>
<td><em>MediaType</em></td>
<td>[string]</td>
<td>It contains the MIME or content type descriptor. The differences between a MIME type and
an internal type name was made, to resolve existing ambigities.</td>
</tr>
<tr>
<td><em>ClipboardFormat</em><strong>deprecated!</strong></td>
<td>[string]</td>
<td>It was interepreted as an identifier inside clipboard.
Please use new property ContentFormat instead of this now.</td>
</tr>
<tr>
<td><em>ContentFormat</em></td>
<td>[string]</td>
<td>It's and identifier, which is used for a deep format detection.
An <type>ExtendedTypeDetection</type> use this value to match
a given content to this type. e.g. It's interpreted as the doc type
of an XML stream or as an identifier inside a file header.
</td>
</tr>
<tr>
<td><em>URLPattern</em></td>
<td>[sequence< string >]</td>
<td>This list contains different URL patterns, which identify this type.
E.g. data base contents can be described by an new defined protocol like "sql://select*".
In combination with a sutable <type scope="com::sun::star::frame">FrameLoader</type> or
<type>ImportFilter</type>/<type>ExportFilter</type> it woul be possible then, to
layout a sql query output into an office frame.</td>
</tr>
<tr>
<td><em>Extensions</em></td>
<td>[sequence< string >]</td>
<td>It contains a list of file extensions, which match this type.
They must be specified as pure extension, without any special signs.
E.g.: "doc", "html" ... but not ".doc".
Using of wildcards is allowed but not very usefull. The may resulting
ambigities with other type registrations can't be resolved anytimes.</td>
</tr>
<tr>
<td><em>DocumentIconID</em></td>
<td>[integer]</td>
<td>It's an ID, which present the number of a corresponding icon.</td>
</tr>
</table>
</p>
<p>
Note:<br>
All elements of this container will be adressed by his internal name,
and it must be an unambigous value.
</p>
*/
interface com::sun::star::container::XNameAccess;
//-------------------------------------------------------------------------
/** provides a write access to the configuration data.
*/
[optional] interface com::sun::star::container::XNameContainer;
//-------------------------------------------------------------------------
/** provides search on the configuration data set.
<p>
Against simple property search it provides some complex algorithms too.
For further informations please read the SDK documentation.
</p>
*/
[optional] interface com::sun::star::container::XContainerQuery;
//-------------------------------------------------------------------------
/** can be used to perform container changes.
<p>
Because the complexness of such configuration set can be very high,
it seams not very usefull to update the undelying configuration layer
on every container change request immediatly. Another strategy can be to
make all changes (adding/changing/removing of items) and call flush at the end.
That will validate the whole container and reject inconsistent data sets.
Only in case all made changes was correct, they will be written back to the
configuration. Further this interface provides the possibelity, that interested
changes listener can be registered too.
</p>
*/
[optional] interface com::sun::star::util::XFlushable;
};
//=============================================================================
}; }; }; };
#endif
|
