Dictionaries
Erklärung der Grafik:
Wird für eine Firma oder Person eine Rolle angelegt ( Lieferant, Kunde o.ä.), werden die in der Rolle gespeicherten Suchbegriffe in einem CX_DICTIONARY/CX_INDEX Objekt (name=“CX_PARTNER“) abgespeichert. In der Grafik ist dargestellt, wie die Suchbegriffe gespeichert werden, wenn die Option "nur für Rolle" in der Rolleneditiermaske ausgewählt wurde.
In diesem Dictionary befinden pro Zeile sich 2 Einträge:
- Der Suchbegriff und
- Pointer auf das dazugehörige Objekt
Damit nicht unterschieden wird, ob der Suchbegriff der Firma in seiner Lieferantenrolle angelegt wurde, und somit in der Kundensuche nicht gefunden wird, ist es standardmäßig nun so, dass alle Suchbegriffe am Partnerobjekt gespeichert werden (im grafischen Beispiel an CX_CORPORATION). Bei Partnern wird der Suchbegriff nicht multilingual gespeichert!
Dies ermöglicht das Auffinden einer Firma in all seinen angelegten Rollen mit allen eingegebenen Suchbegriffen.
Des weiteren gibt es die Möglichkeit, einen Suchbegriff explizit für eine Rolle speichern zu können. Dann wird die Firma auch nur in der Rolle mit dem gespeicherten Suchbegriff gefunden, für die dieser auch angelegt wurde.
Beispiel für das explizite Speichern eines Suchbegriffes für eine Rolle:
Für die Firma Müller wurde in der Lieferantenrolle der Suchbegriff "Monitormüller" nur für die Rolle gespeichert. In seiner Kundenrolle jedoch nur der Suchbegriff "Müller".
Wird jetzt in der Kundensuche der Suchbegriff Monitormüller eingegeben, wird die Firma nicht gefunden. Obwohl Müller ein Kunde ist!
Dictionaries sind keine wirklichen Tabellen, sondern virtuell aus verschiedenen Tabellen zusammengesetzte Gebilde. So kann man im REP verschiedene Dictionaries anlegen. Für die Klasse CX_PARTNER Eines, für die Klasse CX_ITEM ein Anderes usw. In diesen Dictionaries sind dann die Suchbegriffe mit den zugeordneten Objekten verbunden. Der Suchbegriff ist nicht einfach nur ein String/MLString, sondern ein Objekt der Klasse CX_KEYWORD, mit allen ihren Funktionalitäten.
Da das Arbeiten mit Dictionaries einen Unterschied zu der herkömmlichen Vorgehensweise in ClassiX® darstellt, soll sie hier an einem Beispiel verdeutlicht werden.
Will man also die Suchbegriffe für eine Person herausfinden, muss man erst mal das Dictionary auf die Einträge der Klasse CX_PARTNER bringen:
"name=\"CX_PARTNER\"" FindFirst(CX_DICTIONARY) -> dict
Nun enthält die Variable dict ein Dictionary mit Suchbegriffen der Klasse CX_PARTNER.
Weiter benötigt man ein tatsächliches Partnerobjekt, von dem die Suchbegriffe gesucht werden.
"name=\"James Bond\" FindFirst(CX_PERSON) 0 Swap GetElement -> person
Nun können alle für diese Person gespeicherten Suchbegriffe mit dem Befehl GetNames abgefragt werden.
person dict Call(GetNames)
Man erhält als Ergebnis eine Collection der Klasse CX_KEYWORD, durch die man nun durchiterieren kann.
Um an die Suchbegriffe letztendlich ran zu kommen, muss eine weitere Funktion der Klasse CX_KEYWORD aufgerufen werden:
iterate { Call(GetKey) }
Nun erhält man die für diese Person gespeicherten Suchbegriffe.
Es gibt vier verschiedene Arten von Dictionaries:
Dictionaries mit multilingualen Suchbegriffen:
Dictionaries ohne multilinguale Suchbegriffe:
Das CI hinter dem Klassennamen bedeutet, dass diese Dictionaries case insensitive sind. Die Anderen hingegen sind case sensitive. In diesen sollte jeder gespeicherte Wert vorher in uppercase umgewandelt werden.
Die unterschiedlichen Dictionaries haben jeder einen separaten REP, das hält die Ergebnisliste kurz und erlaubt z.B. bei der RegExQuery Funktion einen schnellen Zugriff auf alle Datensätze.
Unterscheidung Teile/Partner:
Beim standardmäßigem Speichern des Suchbegriffes an das Hauptobjekt oder an die Rolle gibt es Unterschiede bei Teilen und Partnern.
Bei Partnern wird standardmäßig der Suchbegriff am Partner gespeichert. Deshalb ist in den Makros "MakeQuery" der Rollenmodule nur ein Query bzw. RegExQuery zu finden, der alle Suchergebnisse aus dem Dictionary holt. Diese werden dann durchlaufen und kontrolliert, ob das entsprechend gefundene Objekt angezeigt werden soll (gehört Suchbegriff zur gesuchten Rolle oder zum Partner, der die gesuchte Rolle besitzt?).
Bei Teilen hingegen ist es nicht so deutlich geteilt. Zum Beispiel sollten alle Suchbegriffe, die für ein Ersatzteil angelegt wurden, auch bei der Teilesuche gültig sein. Denn diese Ersatzteile beziehen sich ja wirklich genau auf dieses Teil. Anders bei Verkaufssets. Diese beziehen sich zwar auch auf ein Hauptteil, jedoch ist der Suchbegriff für das Verkaufsset ziemlich wahrscheinlich nicht das selbe, welches man bei der Teilesuche nach dem Hauptteil benutzen würde. Im MakeQuery ist dies jedoch einheitlich, da alle MakeQuerys vom Modul salebase.mod abgeleitet sind, in den dieses Maktro einmal für alle definiert ist. Dieses "MakeQuery" Makro macht 2 QueryByType bzw. RegExQueryByType. Erst mal werden alle rollenspezifischen Suchbegriffe gesucht und in einer Collection gehalten. Dann wird noch mal nach Dictionary-Einträgen der Klasse CX_ITEM gesucht und geprüft, ob dieses Teil auch die gesuchte Rolle enthält.
Aus dieser ganzen Kontrolle heraus, ob ein Hauptobjekt nun bei der Rolle angezeigt wird oder nicht, entstand der Zählmechanismus, der nicht die zurückgegebenen Objekte nach dem Query begrenzt, sondern bei jedem hinzugefügten Objekt den Zähler um einen erhöht. Wird nämlich beim Query bereits ein Limit übergeben, kann es passieren, dass von diesen hundert zurückgegebenen Objekten 30 gar nicht die Rolle enthalten, und somit nur die 70 passenden angezeigt werden. Obwohl noch 30 weitere hätten angezeigt werden können, wenn von vornherein mehr Objekte zurück gegeben worden wären.
Wenn in einem Dictionary gesucht wird, in dem nur eine Klassenart vorkommt, kann schon beim SELECT vom Suchbegriffsfeld limitSet mit an den Query übergeben werden.
Dies ist z.B. bei Industrieanlagen der Fall. Es wird nicht zusätzlich nach CX_ITEM gesucht und kontrolliert, ob Rolle enthalten ist.
Verwandte Themen
;){kind=link}
;){kind=link}
;){kind=link}
;){kind=link}