Erstellen einer OpenSearch-Beschreibungsdatei in der Windows-Verbundsuche
Beschreibt, wie Sie eine OpenSearch Description-Datei (.osdx) erstellen, um externe Datenspeicher über das OpenSearch-Protokoll mit dem Windows-Client zu verbinden. Die Verbundsuche ermöglicht Es Benutzern, einen Remotedatenspeicher zu durchsuchen und die Ergebnisse in Windows Explorer anzuzeigen.
Dieses Thema enthält folgende Abschnitte:
- OpenSearch-Beschreibungsdatei
- Standardelemente in der Windows-Verbundsuche
- Erweiterte Elemente in der Windows-Verbundsuche
- Vorschauen
- Menüelement "Dateispeicherort öffnen"
- Weitere Ressourcen
- Zugehörige Themen
OpenSearch-Beschreibungsdatei
Eine OpenSearch Description-Datei (.osdx) für die Windows-Verbundsuche muss die folgenden Regeln einhalten:
- Ein gültiges OpenSearch Description-Dokument sein, wie in der OpenSearch 1.1-Spezifikation definiert.
- Geben Sie eine URL-Vorlage mit einem RSS- oder einem Atom-Formattyp an.
- Verwenden Sie die Dateinamenerweiterung .osdx, oder werden Sie der Dateinamenerweiterung .osdx zugeordnet, wenn Sie aus dem Web herunterladen. Ein Server muss z. B. .osdx nicht verwenden. Ein Server kann die Datei mit einer beliebigen Dateinamenerweiterung wie z. B. .xml zurückgeben und so behandelt werden, als wäre es eine OSDX-Datei, wenn er den richtigen MIME-Typ für OpenSearch Description-Dokumente (OSDX-Dateien) verwendet.
- Geben Sie einen ShortName-Elementwert an (empfohlen).
Mininum Erforderliche untergeordnete Elemente
Die folgende OSDX-Beispieldatei besteht aus ShortName - und Url
-Elementen, die die mindestens erforderlichen untergeordneten Elemente sind.
<OpenSearchDescription xmlns="https://a9.com/-/spec/opensearch/1.1/">
<ShortName>My web Service</ShortName>
<Url format="application/rss+xml"
template="https://example.com/rss.php?query=
{searchTerms}&start={startIndex}&cnt={count}" />
</OpenSearchDescription>
Standardelemente in der Windows-Verbundsuche
Zusätzlich zu den untergeordneten Mindestelementen unterstützt die Verbundsuche die folgenden Standardelemente.
Shortname
Windows verwendet den ShortName-Elementwert , um die .searchconnector-ms-Datei (Suchconnector) zu benennen, die erstellt wird, wenn der Benutzer die OSDX-Datei öffnet. Windows stellt sicher, dass der generierte Dateiname nur Zeichen verwendet, die in Windows-Dateinamen zulässig sind. Wenn kein ShortName-Wert angegeben wird, versucht die .searchconnector-ms-Datei stattdessen, den Dateinamen der OSDX-Datei zu verwenden.
Der folgende Code veranschaulicht die Verwendung des ShortName-Elements in einer OSDX-Datei.
<OpenSearchDescription xmlns="https://a9.com/-/spec/opensearch/1.1/">
<ShortName>My web Service</ShortName>
...
</OpenSearchDescription>
BESCHREIBUNG
Windows verwendet den Wert des Description-Elements, um die Dateibeschreibung aufzufüllen, die im Windows-Explorer-Detailbereich angezeigt wird, wenn ein Benutzer eine .searchconnector-ms-Datei auswählt.
<OpenSearchDescription xmlns="https://a9.com/-/spec/opensearch/1.1/">
...
<Description>Searches the example company book catalog</Description>
</OpenSearchDescription>
URL-Vorlage für RSS-/Atom-Ergebnisse
Die OSDX-Datei muss ein Url-Formatelement und ein Vorlagenattribute (eine URL-Vorlage) enthalten, das Ergebnisse im RSS- oder Atom-Format zurückgibt. Das format-Attribut muss für ERGEBNISSE im RSS-Format oder application/atom+xml
für Ergebnisse im Atom-Format auf application/rss+xml
festgelegt werden, wie im folgenden Code gezeigt.
Hinweis
Das Url-Formatelement und das Vorlagenattribute werden allgemein als URL-Vorlage bezeichnet.
<OpenSearchDescription xmlns="https://a9.com/-/spec/opensearch/1.1/">
...
<Url format="application/rss+xml" template="https://example.com/rss.php?query=
{searchTerms}&start={startIndex}&cnt={count}" />
</OpenSearchDescription>
URL-Vorlage für Webergebnisse
Wenn eine Version der Suchergebnisse vorhanden ist, die in einem Webbrowser angezeigt werden kann, sollten Sie ein Url format=text/html
-Element und ein Template-Attribut angeben, wie im folgenden Code gezeigt.
<OpenSearchDescription xmlns="https://a9.com/-/spec/opensearch/1.1/">
...
<Url format="text/html" template="https://example.com/html.php?query={searchTerms}" />
</OpenSearchDescription>
Wenn Sie ein Url format="text/html"-Element und ein Vorlagenattribute angeben, wird in der Windows Explorer-Befehlsleiste eine Schaltfläche angezeigt, wie im folgenden Screenshot gezeigt, mit der der Benutzer einen Webbrowser öffnen kann, um die Suchergebnisse anzuzeigen, wenn der Benutzer eine Abfrage ausführt.
Das Rollover der Abfrage zurück zur Webbenutzeroberfläche des Datenspeichers ist in einigen Szenarien wichtig. Beispielsweise kann ein Benutzer mehr als 100 Ergebnisse anzeigen (die Standardanzahl von Elementen, die der OpenSearch-Anbieter anfordert). Wenn dies der Fall ist, kann der Benutzer auch Suchfunktionen verwenden, die nur auf der Website des Datenspeichers verfügbar sind, z. B. erneute Abfragen mit einer anderen Sortierreihenfolge oder Pivoting und Filtern der Abfrage mit zugehörigen Metadaten.
URL-Vorlagenparameter
Der OpenSearch-Anbieter führt immer die folgenden Aktionen aus:
- Verwendet die URL-Vorlage, um die Anforderung an den Webdienst zu senden.
- Versucht, die in der URL-Vorlage gefundenen Token zu ersetzen, bevor die Anforderung wie folgt an den Webdienst gesendet wird:
- Ersetzt die OpenSearch-Standardtoken, die in der folgenden Tabelle aufgeführt sind.
- Entfernt alle Token, die nicht in der folgenden Tabelle aufgeführt sind.
Unterstütztes Token | Verwendung durch den OpenSearch-Anbieter |
---|---|
{searchTerms} | Ersetzt durch die Suchbegriffe, die der Benutzer im Eingabefeld Windows Explorer Sucheingabe eingibt. |
{startIndex} | Wird beim Abrufen von Ergebnissen in "Pages" verwendet. Ersetzt durch den Index für das erste zurückgegebene Ergebniselement. |
{startPage} | Wird beim Abrufen von Ergebnissen in "Pages" verwendet. Ersetzt durch die Seitenzahl der zurückzugebenden Suchergebnisse. |
{count} | Wird beim Abrufen von Ergebnissen in "Pages" verwendet. Ersetzt durch die Anzahl der Suchergebnisse pro Seite, die Windows Explorer anfordert. |
{language} | Ersetzt durch eine Zeichenfolge, die die Sprache der gesendeten Abfrage angibt. |
{inputEncoding} | Ersetzt durch eine Zeichenfolge (z. B. "UTF-16"), die die Zeichencodierung der gesendeten Abfrage angibt. |
{outputEncoding} | Ersetzt durch eine Zeichenfolge (z. B. "UTF-16"), die die gewünschte Zeichencodierung für die Antwort des Webdiensts angibt. |
Ausgelagerte Ergebnisse
Möglicherweise möchten Sie die Anzahl der pro Anforderung zurückgegebenen Ergebnisse begrenzen. Sie können festlegen, dass eine "Seite" mit Ergebnissen gleichzeitig zurückgegeben werden soll, oder der OpenSearch-Anbieter zusätzliche Ergebnisseiten entweder nach Elementnummer oder Seitenzahl erhält. Wenn Sie beispielsweise zwanzig Ergebnisse pro Seite senden, beginnt die erste seite, die Sie senden, bei Elementindex 1 und bei Seite 1; Die zweite Seite, die Sie senden, beginnt am Elementindex 21 und auf Seite 2. Sie können definieren, wie der OpenSearch-Anbieter Elemente anfordern soll, indem Sie entweder das {startItem}
Token oder {startPage}
in der URL-Vorlage verwenden.
Paging mit dem Elementindex
Ein Elementindex identifiziert das erste Ergebniselement auf einer Ergebnisseite. Wenn Clients Anforderungen mithilfe eines Elementindex senden sollen, können Sie das {startIndex}
Token in Ihrem Url-Elementvorlagen-Attribut verwenden, wie im folgenden Code gezeigt.
<Url format="application/rss+xml"
template="https://example.com/rss.php?query={searchTerms}&start={startIndex}" />
Der OpenSearch-Anbieter ersetzt dann das Token in der URL durch einen Startindexwert. Die erste Anforderung beginnt mit dem ersten Element, wie im folgenden Beispiel veranschaulicht:
https://example.com/rss.php?query=frogs&start=1
Der OpenSearch-Anbieter kann zusätzliche Elemente abrufen, indem er den {startIndex}
Parameterwert ändert und eine neue Anforderung ausgibt. Der Anbieter wiederholt diesen Vorgang, bis er genügend Ergebnisse erhält, um seinen Grenzwert zu erreichen, oder das Ende der Ergebnisse erreicht. Der OpenSearch-Anbieter überprüft die Anzahl der elemente, die vom Webdienst auf der ersten Seite der Ergebnisse zurückgegeben werden, und legt die erwartete Seitengröße auf diese Zahl fest. Diese Zahl wird verwendet, um den {startIndex}
Wert für nachfolgende Anforderungen zu erhöhen. Wenn der Webdienst beispielsweise 20 Ergebnisse in der ersten Anforderung zurückgibt, legt der Anbieter die erwartete Seitengröße auf 20 fest. Für die nächste Anforderung ersetzt {startIndex}
der Anbieter durch den Wert 21, um die nächsten 20 Elemente abzurufen.
Hinweis
Wenn eine vom Webdienst zurückgegebene Seite mit Ergebnissen weniger Elemente als die erwartete Seitengröße aufweist, geht der OpenSearch-Anbieter davon aus, dass er die letzte Seite der Ergebnisse empfangen hat und keine Anforderungen mehr stellt.
Paging mit dem Seitenindex
Ein Seitenindex identifiziert die angegebene Ergebnisseite. Wenn Clients Anforderungen mithilfe einer Seitenzahl senden sollen, können Sie das {startPage}
Token in Ihrem Url-Formatelementvorlagen-Attribut verwenden, um dies anzugeben, wie im folgenden Beispiel veranschaulicht:
<Url format="application/rss+xml"
template="https://example.com/rss.php?query={searchTerms}&page={startPage}" />
Der OpenSearch-Anbieter ersetzt dann das Token in der URL durch einen Seitenzahlenparameter. Die erste Anforderung beginnt mit der ersten Seite, wie im folgenden Beispiel gezeigt:
https://example.com/rss.php?query=frogs&page=1
Hinweis
Wenn eine vom Webdienst zurückgegebene Seite mit Ergebnissen weniger Elemente als die erwartete Seitengröße aufweist, geht der OpenSearch-Anbieter davon aus, dass er die letzte Seite der Ergebnisse empfangen hat und keine Anforderungen mehr stellt.
Page Size
Möglicherweise möchten Sie Ihren Webdienst so konfigurieren, dass eine Anforderung die Größe der Seiten mithilfe eines Parameters in der URL angeben kann. Eine Anforderung muss in der OSDX-Datei mithilfe des {count}
Tokens wie folgt angegeben werden:
<Url format="application/rss+xml"
template="https://example.com/rss.php?query={searchTerms}&start={startIndex}&cnt={count}" />
Der OpenSearch-Anbieter kann dann die gewünschte Seitengröße in Der Anzahl der Ergebnisse pro Seite festlegen, wie im folgenden Beispiel gezeigt:
https://example.com/rss.php?query=frogs&start=1&cnt=50
Standardmäßig stellt der OpenSearch-Anbieter Anforderungen mit einer Seitengröße von 50. Wenn Sie eine andere Seitengröße möchten, geben Sie kein Token an {count}
, und platzieren Sie stattdessen die gewünschte Zahl direkt im Url-Vorlagenelement .
Der OpenSearch-Anbieter bestimmt die Seitengröße basierend auf der Anzahl der Ergebnisse, die bei der ersten Anforderung zurückgegeben wurden. Wenn die erste Seite der empfangenen Ergebnisse weniger Elemente enthält als die angeforderte Anzahl, setzt der Anbieter die Seitengröße für alle nachfolgenden Seitenanforderungen zurück. Wenn nachfolgende Seitenanforderungen weniger Elemente zurückgeben als angefordert, geht der OpenSearch-Anbieter davon aus, dass er das Ende der Ergebnisse erreicht hat.
Erweiterte Elemente in der Windows-Verbundsuche
Zusätzlich zu den Standardelementen unterstützt die Verbundsuche die folgenden erweiterten Elemente: MaximumResultCount und ResultsProcessing.
Da diese erweiterten untergeordneten Elemente in der OpenSearch v1.1-Spezifikation nicht unterstützt werden, müssen sie mithilfe des folgenden Namespaces hinzugefügt werden:
http://schemas.microsoft.com/opensearchext/2009/
Maximale Ergebnisanzahl
Standardmäßig sind Suchconnectors auf 100 Ergebnisse pro Benutzerabfrage beschränkt. Dieser Grenzwert kann angepasst werden, indem das MaximumResultCount-Element in die OSD-Datei eingeschlossen wird, wie im folgenden Beispiel gezeigt:
<OpenSearchDescription xmlns="https://a9.com/-/spec/opensearch/1.1/"
xmlns:ms-ose="http://schemas.microsoft.com/opensearchext/2009/">
...
<ms-ose:MaximumResultCount>200</ms-ose:MaximumResultCount>
</OpenSearchDescription>
Im vorherigen Beispiel wird das Namespacepräfix ms-ose
im OpenSearchDescription-Element der obersten Ebene deklariert und anschließend als Präfix im Elementnamen verwendet. Diese Deklaration ist erforderlich, da MaximumResultCount in der OpenSearch v1.1-Spezifikation nicht unterstützt wird.
Eigenschaftszuordnung
Wenn Ergebnisse vom Webdienst als RSS- oder Atom-Feed zurückgegeben werden, muss der OpenSearch-Anbieter die Elementmetadaten in den Feeds Eigenschaften zuordnen, die von der Windows-Shell verwendet werden können. Der folgende Screenshot veranschaulicht, wie der OpenSearch-Anbieter einige der STANDARD-RSS-Elemente zuordnet.
Standardzuordnungen
Die Standardzuordnungen von RSS-XML-Elementen zu Windows Shell-Systemeigenschaften sind in der folgenden Tabelle aufgeführt. XML-Pfade sind relativ zum Elementelement. Das "media:"
Präfix wird durch den Namespace von Yahoo Search definiert.
RSS-XML-Pfad | Windows Shell-Eigenschaft (kanonischer Name) |
---|---|
Link | System.ItemUrl |
Titel | System.ItemName |
Autor | System.Author |
Pubdate | System.DateModified |
BESCHREIBUNG | System.AutoSummary |
Category | System.Keywords |
Gehäuse/@type | System.MIMEType |
Gehäuse/@length | System.Size |
Gehäuse/@url | System.ContentUrl |
media:category | System.Keywords |
media:content/@fileSize | System.Size |
media:content/@type | System.MIMEType |
media:content/@url | System.ContentUrl |
media:group/content/@fileSize | System.Size |
media:group/content/@type | System.MIMEType |
media:group/content/@url | System.ContentUrl |
media:thumbnail/@url | System.ItemThumbnailUrl |
Hinweis
Zusätzlich zu den Standardzuordnungen von RSS- oder Atom-Standardelementen können Sie andere Windows Shell-Systemeigenschaften zuordnen, indem Sie zusätzliche XML-Elemente in den Windows-Namespace für jede der Eigenschaften einfügen. Sie können auch Elemente aus anderen vorhandenen XML-Namespaces wie MediaRSS, iTunes usw. zuordnen, indem Sie eine benutzerdefinierte Eigenschaftenzuordnung in der OSDX-Datei hinzufügen.
Benutzerdefinierte Eigenschaftenzuordnungen
Sie können die Zuordnung von Elementen aus der RSS-Ausgabe zu Windows Shell-Systemeigenschaften anpassen, indem Sie die Zuordnung in der OSDX-Datei angeben.
Die RSS-Ausgabe gibt Folgendes an:
- Ein XML-Namespace und
- Für jedes untergeordnete Element eines Elements ein Elementname, dem zugeordnet werden soll.
Die OSDX-Datei identifiziert eine Windows Shell-Eigenschaft für jeden Elementnamen in einem Namespace. Die Eigenschaftenzuordnungen, die Sie in Ihrer OSDX-Datei definieren, setzen die Standardzuordnungen außer Kraft, sofern vorhanden, für diese angegebenen Eigenschaften.
Das folgende Diagramm veranschaulicht, wie eine RSS-Erweiterung Windows-Eigenschaften (kanonischer Name) zugeordnet wird.
BEISPIEL-RSS-Ergebnisse und OSD-Eigenschaftenzuordnung
Die folgende RSS-Beispielausgabe identifiziert https://example.com/schema/2009
den XML-Namespace mit dem Präfix "example". Dieses Präfix muss vor dem E-Mail-Element erneut angezeigt werden.
<rss version="2.0" xmlns:example="https://example.com/schema/2009">
...
<item>
<title>Someone</title>
<example:email>Someone@example.com</example:email>
</item>
In der folgenden OSDX-Beispieldatei wird das XML-E-Mail-Element der Windows Shell-Eigenschaft System.Contact.EmailAddress zugeordnet.
<OpenSearchDescription xmlns="https://a9.com/-/spec/opensearch/1.1/"
xmlns:ms-ose="http://schemas.microsoft.com/opensearchext/2009/">
...
<ms-ose:ResultsProcessing format="application/rss+xml">
<ms-ose:PropertyMapList>
<ms-ose:PropertyMap sourceNamespaceURI="https://example.com/schema/2009/" >
<ms-ose:Source path="email">
<ms-ose:Property schema="http://schemas.microsoft.com/windows/2008/propertynamespace" name="System.Contact.EmailAddress" />
</ms-ose:Source>
</ms-ose:PropertyMap>
</ms-ose:PropertyMapList>
</ms-ose:ResultsProcessing>
...
</OpenSearchDescription>
Es gibt einige Eigenschaften, die nicht zugeordnet werden können, da Werte für sie entweder später überschrieben werden oder nicht bearbeitet werden können. Beispielsweise können System.ItemFolderPathDisplay oder System.ItemPathDisplayNarrow nicht zugeordnet werden, da sie aus dem URL-Wert berechnet werden, der entweder in den Link- oder Gehäuseelementen angegeben wird.
Miniaturbilder
Miniaturbild-URLs können für jedes Element mithilfe des elements media:thumbnail url="" bereitgestellt werden. Die ideale Auflösung beträgt 150 x 150 Pixel. Die größten unterstützten Miniaturansichten sind 256 x 256 Pixel. Die Bereitstellung größerer Bilder nimmt mehr Bandbreite ohne zusätzlichen Nutzen für den Benutzer bereit.
Kontextmenü "Dateispeicherort öffnen"
Windows bietet ein Kontextmenü mit dem Namen Dateispeicherort für Ergebniselemente öffnen. Wenn der Benutzer ein Element aus diesem Menü auswählt, wird die "übergeordnete" URL für das ausgewählte Element geöffnet. Wenn es sich bei der URL um eine Web-URL handelt, z https://...
. B. , wird der Webbrowser geöffnet und zu dieser URL navigiert. Ihr Feed sollte eine benutzerdefinierte URL für jedes Element bereitstellen, um sicherzustellen, dass Windows eine gültige URL öffnet. Dies kann erreicht werden, indem Die URL in ein Element in die XML-Datei des Elements eingeschlossen wird, wie im folgenden Beispiel veranschaulicht:
<rss version="2.0" xmlns:example="https://example.com/schema/2009"
xmlns:win="http://schemas.microsoft.com/windows/2008/propertynamespace">
...
<item>
<title>Someone</title>
<link>https://example.com/pictures.aspx?id=01</link>
<win:System.ItemFolderPathDisplay>https://example.com/pictures_list.aspx
</win:System.ItemFolderPathDisplay>
</item>
...
Wenn diese Eigenschaft nicht explizit im XML-Code des Elements festgelegt ist, wird sie vom OpenSearch-Anbieter auf den übergeordneten Ordner der URL des Elements festgelegt. Im obigen Beispiel verwendet der OpenSearch-Anbieter den Linkwert und legt den Wert der Windows-Shell-Eigenschaft System.ItemFolderPathDisplay auf fest "https://example.com/"
.
Anpassen von Windows Explorer-Ansichten mit Eigenschaftenbeschreibungslisten
Einige Ansichtslayouts für Windows Explorer werden durch Eigenschaftenbeschreibungslisten oder Proplists definiert. Eine Proplist ist eine durch Semikolons getrennte Liste von Eigenschaften, z"prop:System.ItemName; System.Author"
. B. , die verwendet wird, um zu steuern, wie Ihre Ergebnisse in Windows Explorer angezeigt werden.
Die Benutzeroberflächenbereiche von Windows Explorer, die mithilfe von Proplists angepasst werden können, werden im folgenden Screenshot veranschaulicht:
Jeder Bereich von Windows Explorer verfügt über einen zugeordneten Satz von Proplists, die selbst als Eigenschaften angegeben werden. Sie können benutzerdefinierte Proplists für einzelne Elemente in Ihren Resultsets oder für alle Elemente in einer Gruppe von Ergebnissen angeben.
Benutzeroberflächenbereich zum Anpassen | Windows Shell-Eigenschaft, die die Anpassung implementiert |
---|---|
Inhaltsansichtsmodus (bei der Suche) | System.PropList.ContentViewModeForSearch |
Inhaltsansichtsmodus (beim Durchsuchen) | System.PropList.ContentViewModeForBrowse |
Kachelansichtsmodus | System.PropList.TileInfo |
Detailbereich | System.PropList.PreviewDetails |
Infotip (QuickInfo des Elements mit dem Mauszeiger) | System.PropList.Infotip |
So geben Sie eine eindeutige Proplist für ein einzelnes Element an:
Fügen Sie in Der RSS-Ausgabe ein benutzerdefiniertes Element hinzu, das die Proplist darstellt, die Sie anpassen möchten. Im folgenden Beispiel wird beispielsweise die Liste für den Detailbereich festgelegt:
<win:System.PropList.PreviewDetails> prop:System.ItemName;System.Author</win:System.PropList.PreviewDetails>
Um eine Eigenschaft auf jedes Element in den Suchergebnissen anzuwenden, ohne die RSS-Ausgabe zu ändern, geben Sie eine Proplist in einem ms-ose:PropertyDefaultValues-Element in der OSDX-Datei an, wie im folgenden Beispiel gezeigt:
<ms-ose:ResultsProcessing format="application/rss+xml"> <ms-ose:PropertyDefaultValues> <ms-ose:Property schema="http://schemas.microsoft.com/windows/2008/propertynamespace" name="System.PropList.ContentViewModeForSearch">prop:~System.ItemNameDisplay;System.Photo.DateTaken; ~System.ItemPathDisplay;~System.Search.AutoSummary;System.Size;System.Author;System.Keywords</ms-ose:Property> </ms-ose:PropertyDefaultValues> </ms-ose:ResultsProcessing>
Layout der Eigenschaften im Inhaltsansichtsmodus
Die Liste der Eigenschaften, die in den Proplists System.PropList.ContentViewModeForSearch und System.PropList.ContentViewModeForBrowse angegeben sind, bestimmt, was im Inhaltsansichtsmodus angezeigt wird. Weitere Informationen zu Eigenschaftenlisten finden Sie unter PropList.
Die Eigenschaften werden gemäß den Zahlen im folgenden Layoutmuster angeordnet:
Wenn wir die folgende Liste von Eigenschaften verwenden,
prop:~System.ItemNameDisplay;System.Author;System.ItemPathDisplay;~System.Search.AutoSummary;
System.Size;System.Photo.DateTaken;System.Keywords
Dann wird die folgende Anzeige angezeigt:
Hinweis
Um eine optimale Lesbarkeit zu erzielen, sollten die eigenschaften, die in der Spalte ganz rechts angezeigt werden, beschriftet werden.
Eigenschaftenlistenflags
Nur eines der in der Proplists-Dokumentation definierten Flags gilt für die Anzeige von Elementen in Layouts im Inhaltsansichtsmodus: "~"
. In den vorherigen Beispielen beschrifte die Ansicht Windows Explorer einige der Eigenschaften, zTags: animals; zoo; lion
. B. . Dies ist das Standardverhalten, wenn Sie eine Eigenschaft in der Liste angeben. Beispielsweise weist "System.Author"
die Proplist auf, die als "Authors: value"
angezeigt wird. Wenn Sie die Eigenschaftenbezeichnung ausblenden möchten, platzieren Sie einen "~"
vor dem Eigenschaftennamen. Wenn die Proplist z. B. aufweist "~System.Size"
, wird die -Eigenschaft nur als Wert ohne die Bezeichnung angezeigt.
Vorschauen
Wenn der Benutzer ein Ergebniselement in Windows Explorer auswählt und der Vorschaubereich geöffnet ist, wird der Inhalt des Elements in der Vorschau angezeigt.
Der in der Vorschau anzuzeigende Inhalt wird durch eine URL angegeben, die wie folgt bestimmt wird:
Wenn die Windows-Shell-Eigenschaft System.WebPreviewUrl für das Element festgelegt ist, verwenden Sie diese URL.
Hinweis
Die Eigenschaft muss im RSS-Format mithilfe des Windows Shell-Namespace bereitgestellt oder explizit in der OSDX-Datei zugeordnet werden.
Wenn nicht, verwenden Sie stattdessen die Link-URL.
Das folgende Flussdiagramm zeigt diese Logik.
Es ist möglich, eine andere URL für die Vorschau als für das Element selbst zu verwenden. Wenn Sie also unterschiedliche URLs für die Link-URL und das Gehäuse oder media:content URL
angeben, verwendet Windows Explorer die Link-URL für die Vorschau des Elements, aber die andere URL für die Dateityperkennung, das Öffnen, Herunterladen usw.
Wie Windows Explorer bestimmt, welche URL verwendet werden soll:
Wenn Sie eine Zuordnung zu System.ItemFolderPathDisplay bereitstellen, verwendet Windows Explorer diese URL.
Wenn Sie keine Zuordnung angeben, identifiziert Windows Explorer, ob die Link- und Gehäuse-URLs unterschiedlich sind. Wenn ja, verwendet Windows Explorer die Link-URL.
Wenn die URLs identisch sind oder nur eine Link-URL vorhanden ist, analysiert Windows Explorer den Link, um den übergeordneten Container zu finden, indem der Dateiname aus der vollständigen URL entfernt wird.
Hinweis
Wenn Sie erkennen, dass die URL-Analyse zu unzustellbaren Links für Ihren Dienst führen würde, sollten Sie eine explizite Zuordnung für die Eigenschaft bereitstellen.
Menüelement "Dateispeicherort öffnen"
Wenn ein Element mit der rechten Maustaste auf ein Element klickt, wird der Menübefehl Dateispeicherort öffnen angezeigt. Mit diesem Befehl wird der Benutzer an den Container für oder den Speicherort dieses Elements gelangen. Wenn Sie beispielsweise in einer SharePoint-Suche diese Option für eine Datei in einer Dokumentbibliothek auswählen, wird das Stammverzeichnis der Dokumentbibliothek im Webbrowser geöffnet.
Wenn ein Benutzer auf Dateispeicherort öffnen klickt, versucht Windows Explorer, einen übergeordneten Container mithilfe der im folgenden Flussdiagramm gezeigten Logik zu finden:
Zusätzliche Ressourcen
Weitere Informationen zum Implementieren eines Suchverbunds zu Remotedatenspeichern mithilfe von OpenSearch-Technologien in Windows 7 und höher finden Sie unter "Zusätzliche Ressourcen" unter Verbundsuche in Windows.
Zugehörige Themen