Condition über Bilder-Listview funktioniert nicht (Meta-Daten)

[Carrear]

Hey Leute,

ich habe eine Listview über einen Order mit Bildern:

Code: Alles auswählen

<we:listview type="document" workspaceID="7995" condition="$MyProductCond" order="we_creationdate" desc="true" searchable="false" recursive="true" contenttypes="image/*">
	<we:repeat>
		<we:field nameto="imgID" to="global" type="text" name="WE_ID" />
		<we:field type="text" name="Title" />
		<we:img id="$GLOBALS[imgID]" thumbnail="Bilddatenbank" />
		<we:field type="text" name="WE_TEXT" />
		<we:field type="text" name="Description" />
		<we:field type="text" name="Keywords" />
		<we:img id="$GLOBALS[imgID]" only="src" />
	</we:repeat>
</we:listview>

Das klappt von der ausgabe her auch (Habe das markup mal rausgeschmissen zur Übersichtlichkeit). Aber sobald folgende Condition greift findet der Listview nichts mehr:

Code: Alles auswählen

$MyProductCond = "Title like '%".$MyCondition."%' OR Description like '%".$MyCondition."%' OR Keywords like '%".$MyCondition."%'";

Was geht da schief?

VG Martin

[Carrear]

Nur zur Info: Ist nicht mehr akut da ich es jetzt über einen Listview type=search gemacht habe und einem darin verschachtelten Listview um die Felder des einzelnen Dokuments zu bekommen. Aber die Lösung würde mich trotzdem brennend interessieren.

VG Martin

[AndreasWitt]

... versuch doch mal folgendes:

Code: Alles auswählen

<we:condition name="myCondition">
	<we:conditionAdd field="Title" compare="LIKE" var="MyCondition" type="global" property="true" />
	<we:conditionOr />
	<we:conditionAdd field="Description" compare="LIKE" var="MyCondition" type="global" property="true" />
	<we:conditionOr />
	<we:conditionAdd field="Keywords" compare="LIKE" var="MyCondition" type="global" property="true" />
</we:condition>

[mokraemer]

Die Lösung ist einfach: bei den Dokumenten kann man nicht nach mehr wie einem Kriterium filtern, jedenfalls nicht mittels "Oder" ich meine "Und" ginge mittlerweile.

[Carrear]

Und warum?

[WBTMagnum]

Die Frage habe ich mir auch schon mal gestellt.

Ein Blick in die Struktur von Dokumenten und Objekten gab schnell Aufschluss:
* Dokumente legen die Daten in der Tabelle Content ab
* Objekte speichern die Daten in einer dafür vorgesehen Spalte

Bei Objekten hast du daher die für einen Vergleich notwendigen Daten sofort bei der Hand. Bei Dokumenten musst du die Daten erst über JOINs in die Abfrage holen. Das lässt sich dynamisch nicht so einfach umsetzen und ist höllisch ineffizient.

Liebe Grüße,
Sascha

[mokraemer]

@Sascha: genau. Bei den Dokumenten geht der AND-Vergleich noch über Mengen-Operationen, die von der DB so aufgelöst werden können. Bei der Oder-Variante würde sich zwar Martinsfragestellung noch abbilden lassen (eines der Felder enthält immer den gleichen Wert) aber generisch ist das die Hölle.

[Carrear]

Hm. Wird in der Suche ja auch gemacht. Also wenn es so ineffizient ist, lässt es sich nicht ändern. Warum ich es aber sehr schade finde ist, weil wir immer mehr dazu tendieren die Meta-Daten-Felder für die richtige Inhaltspflege zu nutzen. D.h. z.B. der ausgegebene Seitentitel landet im Title, der Anrisstext in Description und die "Tags" in Keywords. Wir haben festgestellt, dass es für den Kunden

• wesentlich einfacher zu pflegen ist, weil es weniger Felder sind und weil der konkrete Anwendungsfall für unerfahrene Redakteure einfacher verständlich ist
• besser ist, was die Suchmaschinenbewertung angeht. Früher wurden mit Vorliebe Unternehmensnamen und allgemeine Keywords der Branche sinnlos aufgelistet. Werden die Keywords aber auf der Seite i.V.m. dem Inhalt ausgegeben, dann machen sich Redakteure richtig Gedanken. Das steigert die Qualität der Seiten ungemein

Die anderen Felder die man als Input, etc. anlegt sind aber in der Content-Tabelle? Oder lassen sich da auch keine "or" Abfragen erstellen? Aus meiner Sicht sind solche Abfragen in Zeiten von möglichst flexibler Inhaltszusammenstellung durch Distribution und Aggregation fast unverzichtbar!? Alles auf Objekte umstellen ist da aber aus Gründen der Pflegbarkeit auch nicht immer das coolste.

VG Martin

[WBTMagnum]

Hm. Wird in der Suche ja auch gemacht.

Was meinst du damit? Die Suche geht auf den Index (=Text). Da kannst du keine Datumsvergleiche oder ähnliches machen.

Also wenn es so ineffizient ist, lässt es sich nicht ändern.

Mit den bestehenden Strukturen / Abfragemöglichkeiten ist es leider aufwändig und ineffizient. Mit entsprechendem Einsatz und Aufwand ließe sich da vermutlich schon eine generische Lösung bauen. Das ist halt nichts das sich schnell umsetzen lässt.

Warum ich es aber sehr schade finde ist, weil wir immer mehr dazu tendieren die Meta-Daten-Felder für die richtige Inhaltspflege zu nutzen. D.h. z.B. der ausgegebene Seitentitel landet im Title, der Anrisstext in Description und die "Tags" in Keywords. ...[/list]

Machen wir genau so .

Die anderen Felder die man als Input, etc. anlegt sind aber in der Content-Tabelle?

Ja! Sowohl Meta-Daten als auch im Template angelegt Felder landen in der Content-Tabelle. Meta-Daten sind auch nichts anderes als vordefinierte <we:input/>s (Title, Description, Keywords).

Oder lassen sich da auch keine "or" Abfragen erstellen?

Selbes "Problem".

Aus meiner Sicht sind solche Abfragen in Zeiten von möglichst flexibler Inhaltszusammenstellung durch Distribution und Aggregation fast unverzichtbar!? Alles auf Objekte umstellen ist da aber aus Gründen der Pflegbarkeit auch nicht immer das coolste.

Sehe ich genau so. Das wird sich nur leider nicht schnell ändern lassen.

Anm.: Bei einem anderen Projekt haben wir genau aus dem Grund noch eine extra Suchmaschine (Elastic Search) dazu gepappt. Das greift die Daten direkt aus der DB und sorgt für die Durchsuchbarkeit.

Liebe Grüße,
Sascha

[mokraemer]

Verknüpfte Abfragen über die LV's gehen sowieso erst seit der 7.0.1/7.0.2 wieder richtig.
Es war schon recht aufwändig die Und-Abfrage zu korrigieren. Das ist idr. der häufigste Fall.
So, um das Problem vielleicht mal deutlich zu machen: Jedes Feld in einem Dokument ist ein Eintrag in der DB - geht auch nicht anders (und macht auch Sinn), weil die Dokumente ja nicht gleich sind, und durch vieles (Blöcke etc) ja viel flexibler als Objekte. D.h. zu jedem Dokument existieren X Paare aus Name und Inhalt. Eine Suche kann nur dann sinnvoll und effizient funktionieren, wenn man möglichst schnell die Ergebnismenge klein bekommt. Wenn die DB wirklich jede Zeile mit dem Suchtext vergleichen muß und wir dies über "und"/"oder" auch noch mehrfach hätten, dann braucht die DB einfach lange um zu entscheiden ob ein Dokument gefunden wurde oder nicht.

Die Meta Felder hätten evtl. nicht in der Content-Tabelle liegen müssen. das ist aber schon immer so und das würde ja auch nur ein Spezialproblem lösen.

@Sascha: wenn du eine Idee hast, wie eine Abfrage hier sinnvoll generisch aussehen könnte, gerne - nur mir ist da nichts sinnvolles mehr eingefallen.