FMK2018-Portalfilterung und Sortierung Gerhard Schwingenschloegl

9. FileMaker Konferenz | Liechtenstein | 17.-20. Oktober 2018
www.filemaker-konferenz.com
Portalfilterung über Beziehungsgraph und Portalfilter
sowie Sortierung des Portals
Gerhard Schwingenschlögl
Portalfilterung und Portalsortierung

Portalfilterung- und Sortierung / Gerhard Schwingenschlögl
Über den Sprecher
• Geboren 1958 als „ÖSI“ in Wernstein an der
Grenze zu Deutschland
• Speditionskaufmann, Kraftfahrer,
Vermögensberater, Verkäufer, Mitarbeiter in
Marketing und Produktion, Kundenbetreuer in
Softwareunternehmen, Verkaufsaußen- und
Innendienst, Analytiker
• Handwerker im eigenen Haus und Garten
• Hobbyfotograf

Über den Vortrag
• Es ist nichts neu erfundenes zu
Portalfilterung
• Es greift auf praxistaugliche
Ansätze anderer Entwickler zu
• Es ist mein Weg …
• … und ich hoffe, das sich keine
Fehler und Falschaussagen
eingeschlichen haben

Grundsätzliches
Mastertabelle
(Kopfdaten)
Detailtabelle
(im Portal)
1:n

Grundsätzliches
• Es werden immer nur ganze Felder abgeglichen
• Sinnvollerweise eignen sich Felder vom Typ Text, Zahl, Datum, Zeit und Formel zum Abgleich
• Auf der Mastertabelle können verwendet werden:
• „normale“ Felder
• Globale Felder
• Formelfelder
• Auf der Detailtabelle können verwendet werden:
• „normale“ Felder
• Formelfelder

Grundsätzliches
• Die Filterung über eine Beziehung sollte - meiner Meinung nach - gegenüber der Portalfilterung an erster Stelle
stehen
• Oft ist es der Server, der die Daten bereit stellt, und der nimmt dem Client die Arbeit ab
• Die Daten können schon vorsortiert kommen
• Es werden nur die angeforderten Daten im Portal als Ergebnismenge geliefert
• Eine Portalfilterung sollte nur mehr eine Verfeinerung der Filterung bieten
• Die Ergebnismenge der bereit gestellten Daten wird dadurch im Portal nicht weniger!
• Die Technik zur Filterung ist auf einem Layout ist gleich

Variante 1
• Die Ergebnismenge wird durch die Art der Beziehung
bestimmt
• Oft ist es nur ein einziges Feld das abgeglichen
wird:
(Primarykey mit Foreignkey)
• Das entspricht dem Muster, welches verwendet wird,
um Daten über ein Portal zu erfassen
• Eine weitere Filterung wird über das Portal gemacht
Auf einem Layout gibt es ein Portal mit Detaildatensätzen, der Hauptdatensatz wird nicht verlassen

Variante 1
• Die Ergebnismenge wird durch Portalfilterung nicht
weniger
• Formeln und Statistikfelder beeinträchtigen die
Performance (speziell im Netzwerk)
• Die Anzahl der gefundenen Datensätze im Portal
muss extra ermittelt werden
• Mehraufwand für Filterung, welche evtl. schon über
Beziehungsgraphen erledigt werden könnte
Nachteile der Portalfilterung:

Variante 1
• Es kann Volltextsuche verwendet werden
• Es können Teile eines Feldes gesucht werden
• Es kann für jedes Feld ein Suchfeld geben
• Es kann ein Suchfeld für mehrere Felder verwendet
werden (mehrere Felder werden zu einem
zusammengefasst werden, und dieses wird
durchsucht)
Vorteile der Portalfilterung:

Variante 2
• Die Ergebnismenge wird durch die Art der Beziehung
bestimmt
• Es werden mehrere Felder abgeglichen
• Eine weitere Filterung wird über das Portal gemacht,
ist aber oft gar nicht mehr notwendig
Auf einem Layout gibt es ein Portal mit Detaildatensätzen, der Hauptdatensatz wird nicht verlassen

Variante 2
• Die Ergebnismenge wird durch Filterung über
Beziehungsgraph weniger
• Die Performance - speziell im Netzwerk- wird besser
• Die Anzahl der gefundenen Datensätze im Portal
stimmt mit der Ergebnismenge überein
• Oft reicht schon diese Art der Filterung, eine
zusätzliche über das Portal ist nicht mehr notwendig
Vorteile bei einer Filterung:

Variante 2
Nachteil für eine Filterung: • Nicht alle Felder eignen sich, denn
• es müssen schon für jedes Feld alle
vorhandenen Werte zu Beginn vorhanden sein,
damit die vollständige Ergebnisliste angezeigt
wird
• Ein leeres Feld auf der Mastertabelle reicht aus,
um kein Ergebnis im Portal anzuzeigen
• Es muss immer das ganze Feld abgeglichen
werden

Der Ablauf des Vortrages
• Im ersten Teil wird die Filterung über Beziehungsgraphen gezeigt
• Hier werden sinnvollerweise nur Felder verwendet, welche eine Zusammenfassung nach
Kategorien zulässt und demnach nicht tausende verschiedene Einträge vorweist.
z.Bsp.: Länderkennzeichen, Bundesland, Kundenklassifizierung, Verkaufsgebiet, …
• Im zweiten Teil wird die Filterung über das Portal gezeigt
• Hier werden alle anderen Felder durchsucht, welche eine hohe Anzahl von verschiedenen
Einträgen aufweist
z.B. PLZ, Ort, Kundenname, Straßenbezeichnung, …
• Im dritten Teil wird auf die Portalsortierung eingegangen

Teil 1
• Unsere vorbereitenden Arbeiten finden im Datenbankfenster und Beziehungsgraphen statt
• In der Demo-Datei der Blutspendedatenbank sind es die Tabellen MAS_Mastertabelle (ANKER)
und ADR_Adresstabelle (BOJE)
• Als Abgleichsfeld wird zu Beginn _1 verwendet. In beiden Tabellen ist für jeden Datensatz eine 1
eingetragen. Damit gibt es zwischen beiden Tabellen immer eine gültige Beziehung.
• Bleibt das Feld _1 in der Ankertabelle als normales Speicherfeld, kann sich der Wert beim
Blättern ändern, wenn zu jedem Datensatz ein anderer Wert gespeichert wurde.
• Für den „statischen“ Modus ändern wir jedoch dieses Feld auf ein globales Speicherfeld
• Die Beziehung für unser Beispiel sieht so aus

Teil 1
• Das Layout zeigt oben die Mastertabelle, dazwischen mögliche Filterungen und unten das
Ergebnis in einem Portal an.

Teil 1
• Kein Ergebnis im Blättermodus?
Wir erinnern uns - beim Abgleich müssen in beiden Tabellen gültige Werte stehen.
• Vielleicht ist das globale Feld in der Mastertabelle noch leer?
• Vielleicht wurde noch kein Datensatz in der Mastertabelle angelegt?
• Vielleicht passt noch kein Datensatz in der Detailtabelle zu dem Abgleichfeld in der
Mastertabelle?

Teil 1
Sonderfall für die Mastertabelle
• Normalerweise ist auf der linken Seite der Beziehung nur ein Wert, welcher mit n Werten der
Detailtabelle verglichen wird.
• FileMaker kann aber auch anders. Wenn auf der linken Seite eine Liste von Werten - getrennt mit
einem Absatzzeichen - in dem Abgleichsfeld ist, dann wird jede Zeile extra mit der Detailtabelle
verglichen.
Wir müssen also dafür sorgen, dass gleich beim Aufruf des Layouts diese Liste in den globalen
Feldern vorhanden ist.

Teil 1
Sonderfall für die Mastertabelle
• Dafür eignen sich:
• Wertelisten (dynamisch)
• Der Einsatz einer Magic Value List
(nachzulesen im FMM 201301 und 201302 von Arnold Kegebein)

Teil 1
Beispiel Werteliste:
Ein Feld aus der entsprechenden Tabelle
verwenden, um es dynamisch in die Werteliste
zu bringen
Ein globales Feld auswählen, und diesem diese
Werteliste als Einblendmenü zuweisen.

Teil 1
DEMO-Datei
In dieser Datei sind auf mehrere Layouts die einzelnen
Zwischenschritte ersichtlich

Teil 2
• Portalfilter werden über die Eigenschaften des Ausschnittes festgelegt

Teil 2
• Hier braucht man zu jedem Feld, welches in dem Portal gefiltert werden soll, ein
entsprechendes Feld auf dem Layout, mit dem abgeglichen werden kann.
Ähnlich wie im Teil 1 zum Beziehungsfilter

Teil 2
• Verwendet werden können auf dem Layout:
• „Normale Felder“
• Globale Felder
• $$Variablen
• Aus dem Portal:
• Felder, welche auch zu dem Portal gehören
(beim Kopieren von Portalen und Wechsel der Datenquelle kann es passieren, dass die Felder nicht
richtig referenzieren)

Teil 2
• Um Daten in einem Portal anzeigen zu können, muss eine Bedingung erfüllt
(wahr) sein
• Zum Beispiel
• Wahr im Gegensatz zu „Wahr“
• 0
• 1 = 1
• FeldnameAusDemPortal = FeldinhaltAufDemLayout
• FeldnameAusDemPortal = $$Variable
Hier wird immer noch mit dem ganzen Feldinhalt verglichen

Teil 2
• Weil nun eine Bedingung gesetzt ist, wird logischerweise kein Datensatz
angezeigt, wenn das Feld auf dem Layout leer ist.
Abhilfe:
Ein zweites Portal, welches keine Filterbedingung hat und wechselweise ein- und
ausgeblendet wird, je nachdem das Suchfeld einen Inhalt aufweist oder leer ist
ODER
Besser mit einer Falls-Bedingung die Bedingung für die Anzeige auf WAHR
stellen, wenn das Suchfeld leer ist.

Teil 2
Falls-Bedingung mit ganzem Feldinhalt
Falls(
FeldinhaltAufDemLayout = „“; Vergleichsausdruck
WAHR; Wenn-Teil
FeldinhaltAufDemLayout = FeldAusDemPortal Sonst-Teil
)
Mit dieser Portalbedingung wird immer ein Ergebnis im Portal angezeigt, wenn die
Bedingung erfüllt ist - und - man braucht kein zweites Portal.
Bei leerem Suchfeld auf dem Layout werden ALLE Datensätze angezeigt,
ansonsten nur die, welche zu dem Suchbegriff passen.

Teil 2
Falls-Bedingung mit Wortteilen als Feldinhalt
Dazu verwenden wir die Funktion
MusterAnzahl ( Text ; Suchtext )
und bauen diese in die Falls-Bedingung ein.
MusterAnzahl ( FeldAusDemPortal ; FeldinhaltAufDemLayout )
Falls(
FeldinhaltAufDemLayout = „“; Vergleichsausdruck
WAHR; Wenn-Teil
FeldinhaltAufDemLayout = MusterAnzahl ( FeldAusDemPortal ; FeldinhaltAufDemLayout ) Sonst-
Teil
)

Teil 2
Refresh
Eine Portalfilterung braucht meist ein Objekt aktualisieren und/oder Fenster
aktualisieren (mit JOIN-Ergebnisse im Cache löschen)
Manchmal hilft auch nur mehr ein „Schreibe Datensatz“, um die Daten im
Ausschnitt sehen zu können.

Teil 2
Refresh
Damit das nicht immer manuell gemacht werden muss, hilft ein kleines Script,
welches wir als TRIGGER beim Verlassen des Suchfeldes auslösen lassen.

Teil 2
Mehrere Falls-Bedinungen
Oft ist es so, dass ein Feld zum Filtern eines Portals zu wenig ist. Nach dem
bereits erlernten Schema kann man auch die Filterbedingung auf mehrere
Suchfelder erweitern.
Für jedes Suchfeld auf dem Layout, braucht es eine Falls-Bedingung im
Portalfilter, welche mit einem UND verknüpft wird.

Teil 2
Ein Suchfeld mit einem Portalfilter
Auf dem Layout gibt es das Suchfeld g_Search
Dem Portal wurde ein Formelfeld f_Heuhaufen hinzugefügt, welches die Felder City und Surname,
getrennt mit eine Leerzeichen zusammenzieht.
Der Portalfilter dazu lautet:

Teil 2
Ein Suchfeld mit einem Portalfilter
Auf diese Weise werden alle Felder, welche sich im Formelfeld befinden, nach
einem Suchbegriff durchsucht, egal in welchem Feld er vorkommt.
Das Ergebnis entspricht schon ansatzweise einer Schnellsuche.
Leider werden die Umlaute, ss und ß in einem Portalfilter nicht gleicherweise
behandelt.
Jäger findet nicht Jaeger
Muss findet nicht Muß
und umgekehrt

Teil 2
Ein Suchfeld mit einem Portalfilter - in Kombination mit einer
CustomFunction
Mit Google-Suche bin ich auf eine CustomFunction gestoßen, deren Urheber ich
leider nicht mehr weiß.
Es erweitert die eben vorgestellte Suchmöglichkeit insoweit, dass in einem Feld
auch mehrere Suchbegriffe eingegen werden können, und das Portal nach allen
Feldern durchsucht, welche im Filter angegeben wurden.

Teil 2
CustomFunction
Die Custom Function

Teil 2
CustomFunction
Die Portalfilterbedingung

Teil 2
CustomFunction
Layoutbeispiel
Mit dieser Funktion lassen sich Begriffe suchen, welche als Wort beginnen. Je
mehr eingegeben wird, desto kleiner wird die Trefferliste.
Die Reihenfolge der Eingabe ist völlig egal.

Teil 2
CustomFunction
Layoutbeispiel
Die Reihenfolge der Eingabe ist völlig egal.

Teil 2
Es ist egal, nach welchem Feld zuerst gesucht wird. Nachdem das erste Feld
verlassen wurde, wird die Liste nach diesem Kriterium gefiltert.
Gibt man im nächsten Feld eine weitere Suchbedingung ein, werden in der
vorhanden Liste nach beiden Kriterien gesucht.
Nachdem es ja eine UND-Bedingung ist, müssen alle Bedingungen erfüllt sein,
um Datensätze im Portal anzuzeigen.
Es können demnach mehrere Felder für die Suche bereit gestellt werden. Wichtig
ist nur, dass man sich an obiges Schema hält und jedes weitere Suchfeld in der
Filterbedingung des Portals mit einem UND erweitert.

Teil 3
Portal sortieren
Als Standard kann man ein Portal nur nach einer eingestellten Sortierung
sortieren lassen.

Teil 3
Portal sortieren
Man verwendet meist nur ein Feld zur Sortierung. Hat man mehrere Felder auf
dem Portal, will man normalerweise nicht auf ein Feld fixiert sein, sondern von
einem Feld auf ein anderes die Sortierung legen.
Die folgende Sortiermöglichkeit,
welche gänzlich ohne Scriptschritt auskommt,
ist von Klaus Kegebein aus dem Jahr 2008, welches im FileMakerMagazin
200801 erschienen ist.

Teil 3
Portal sortieren
Wir brauchen in der Tabelle, wo die Daten im Portal angezeigt werden sollen,
zwei Felder.
g_Sortierfeld wird über das Layout mittels einer Werteliste gefüllt.
f_Sortierung beinhaltet die Formel, welche die über die Werteliste getroffene
Auswahl in dieses Feld überträgt.

Teil 3
Portal sortieren
Die Falls-Formel für die Sortierung

Teil 3
Portal sortieren Eine passende, einfache Werteliste

Teil 3
Portal sortieren Im Layoutmodus

Teil 3
Portal sortieren Die Portalsortierung

Teil 3
Portal sortieren Die Auswahl auf dem Layout

Teil 3
Portal sortieren
Will man auf eine absteigende Sortierung
umstellen, dann benötigt man eine Kopie
des Portals und richtet sich die gleiche
Bedingung ein, aber nur absteigend
sortiert.
Ein weiteres Feld, welches nur die Werte
AUF und AB enthält, liefert die
Ausblendbedingung, welche zu dem
jeweiligen Sortierschlüssel des Portals
passt.

Teil 3
Portal sortieren Die Ausblendbedingung im Inspektor

Vielen Dank unseren Sponsoren
Danke für das Bewerten dieses Vortrages

FMK2018-Portalfilterung und Sortierung Gerhard Schwingenschloegl

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (10)

Ähnlich wie FMK2018-Portalfilterung und Sortierung Gerhard Schwingenschloegl

Ähnlich wie FMK2018-Portalfilterung und Sortierung Gerhard Schwingenschloegl (20)

Mehr von Verein FM Konferenz

Mehr von Verein FM Konferenz (20)

FMK2018-Portalfilterung und Sortierung Gerhard Schwingenschloegl