<html> <head> <title>Service ExtendedTypeDetection</title> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <link rel="stylesheet" type="text/css" href="../../../../idl.css"> </head> <body> <div id="adc-idlref"> <a name="_top_"> </a><table class="navimain" border="0" cellpadding="3"> <tr> <td class="navimain"><a href="../module-ix.html" class="navimain">Overview</a></td> <td class="navimain"><a href="module-ix.html" class="navimain">Module</a></td> <td class="navimain"><a href="ExtendedTypeDetection-xref.html" class="navimain">Use</a></td> <td class="navimain"><a href="#devmanual" class="navimain">Devguide</a></td> <td class="navimain"><a href="../../../../index-files/index-1.html" class="navimain">Index</a></td> </tr> </table> <table class="navisub" border="0" cellpadding="0"> <tr> <td class="navisub">Included Services</td> <td class="navisub"><a href="#ExportedInterfaces" class="navisub">Exported Interfaces</a></td> <td class="navisub">Properties' Summary</td> <td class="navisub">Properties' Details</td> </tr> </table> <hr> <table border="0" width="100%" cellpadding="5" cellspacing="3" class="title-table" style="margin-bottom:6pt;"> <tr> <td><p class="namechain"><a href="../../../../module-ix.html" class="namechain">::</a> <a href="../../../module-ix.html" class="namechain">com</a> :: <a href="../../module-ix.html" class="namechain">sun</a> :: <a href="../module-ix.html" class="namechain">star</a> :: <a href="module-ix.html" class="namechain">document</a> :: </p> </td> </tr> <tr> <td class="title">service ExtendedTypeDetection</td> </tr> <tr> <td><dl> <dt><b>Description</b></dt> <dd>describes a class of service which will be used for deep <a href="TypeDetection.html">TypeDetection</a> in a generic way </dd> <dd><p> Due to the registered types, flat <a href="TypeDetection.html">TypeDetection</a> is already possible, i.e. the assignment of types (e.g. to a URL) only on the basis of configuration data. If, however, you imagine special cases (e.g. modifying the file extension of a Writer file from .sdw to .doc), it quickly becomes clear that you cannot always get a correct result with flat detection. To be certain to get correct results, you need deep detection, i.e. the file itself has to be examined. And that is exactly the function of DetectServices. They get all the information collected so far on a document and then decide which type to assign it to. In the new modular model, such a detector is meant as UNO service which registers itself in the office and is requested by the generic type detection if necessary. <br> Therefore you need two pieces of information: <ul> <li> The <strong>ServiceName</strong> - This must be a valid UNO service name. It is also an entry in the corresponding configuration list. <br> Example: "com.company.devision.DetectService" <br> Note that this realy means the implementation name of the service. Because it's not possible otherwise to distinguish between more then one registered detect services in same office installation! But it's possible for the generic type detection to create an uno service by his implementation name too. </li> <li> A list of <strong>Types</strong> able to be recognized by this service - You can also implement and register detectors for groups of types. </li> </ul> See service <a href="TypeDetection.html">TypeDetection</a> and his configuration for further informations. </p> </dd> <dt><b>See also</b></dt> <dd><a href="TypeDetection.html">TypeDetection</a></dd> </dl> <a name="devmanual"> </a><dl> <dt><b>Developers Guide</b></dt> <dd><a href="http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/OfficeDev/Integrating_Import_and_Export_Filters">OfficeDev - Integrating Import and Export Filters</a></dd> <dd><a href="http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/OfficeDev/XML_Filter_Detection">OfficeDev - XML Filter Detection</a></dd> </dl> </td> </tr> </table> <hr> <a name="ExportedInterfaces"/><table border="1" width="100%" cellpadding="5" cellspacing="0" class="subtitle"> <tr> <td class="subtitle" colspan="2">Exported Interfaces</td> </tr> <tr> <td class="imsum_left"><a href="XExtendedFilterDetection.html">XExtendedFilterDetection</a></td> <td class="imsum_right"><dl> <dt><b>Description</b></dt> <dd>makes the deep detection </dd> <dd><p> Generic type detection searchs for a registered DetectService for an already flat detected type. If any could be found it will be created and used by calling methods of this interface. It gets a <a href="MediaDescriptor.html">MediaDescriptor</a> which contains information about the document which should be detected and must return <ul> <li>an internal type name for detected format</li> <li>or <b>NULL</b> if format is unknown nor supported.</li> </ul> May be that given descriptor already includes the opened document stream as parameter <a href="MediaDescriptor.html">MediaDescriptor</a>::<a href="MediaDescriptor.html#InputStream">InputStream</a>. Then this one should be used everytime. If it's not included in descriptor the value of <a href="MediaDescriptor.html">MediaDescriptor</a>::<a href="MediaDescriptor.html#URL">URL</a> must be used to open requested ressource by this service. <br> Note: The stream should be added to the descriptor if it wasn't a part of them before. So further steps on the whole detection process can use it and will perform her work. It's further not allowed to hold a reference to this stream any longer. Only copies will be valid then. Otherwise nobody can close this stream then. </p> </dd> </dl> </td> </tr> </table> <br> <a href="#_top_">Top of Page</a><hr size="3"><p class="copyright" align="center">Copyright © 2008 Sun Microsystems, Inc.</p> </div> <!-- id="adc-idlref" --> </body> </html>
distrib
>
Mandriva
>
2008.1
>
x86_64
>
media
>
main-testing
>
by-pkgid
>
2c50825dd66d0497b96a67f7fab2ee84
>
files
>
2358
