Live-Demo
23k

NocoBase 0.20: Unterstützung für mehrere Datenquellen

NocoBase 0.20 führt Unterstützung für mehrere Datenquellen ein, Anpassungen der Sammlungsverwaltung, Nicht-ID-Primärschlüssel, verbesserte Benutzer- und Berechtigungsschnittstellen sowie neue Workflow-Knoten für mehr Flexibilität und Leistung.

NocoBase team |

Neue Funktionen

Unterstützung für mehrere Datenquellen

Das Plugin „Data Source Manager“ wurde hinzugefügt, um alle Collections und Felder für Datenquellen zu verwalten. Der Data Source Manager bietet eine zentrale Oberfläche zur Verwaltung von Datenquellen, jedoch keine Möglichkeit, auf Datenquellen zuzugreifen. Es muss in Verbindung mit verschiedenen Datenquellen-Plugins verwendet werden. Derzeit werden folgende Datenquellen unterstützt:

Darüber hinaus können weitere Datenquellen erweitert werden, bei denen es sich um gängige Datenbanktypen oder Plattformen handeln kann, die APIs (SDKs) bereitstellen.

Data Source Manager

Anpassung der Collections-Verwaltung

Der ursprüngliche „Collection Manager“ wurde nach „Datenquelle > Hauptdatenbank > Konfiguration“ verschoben.

Konfiguration der Hauptdatenbank

Unterstützung für Nicht-ID-Felder als Primärschlüssel und Beziehungseinschränkungen

Beim Erstellen einer Collection kann ausgewählt werden, kein ID-Feld zu erstellen.

Vordefinierte Felder

Ganzzahlfelder können als Primärschlüssel verwendet werden.

Ganzzahlfelder können als Primärschlüssel verwendet werden

Einzeilige Textfelder können ebenfalls als Primärschlüssel verwendet werden.

Einzeilige Textfelder können ebenfalls als Primärschlüssel verwendet werden

Beziehungseinschränkungen unterstützen die Auswahl anderer Felder mit gesetzten Unique-Indizes als Nicht-Primärschlüsselfelder.

Anpassung der Drag-and-Drop-Sortierung

Ein Feld vom Typ „Sortierung“ wurde hinzugefügt. Sortierfelder werden beim Erstellen von Collections nicht mehr automatisch generiert und müssen manuell erstellt werden.

Wenn ein Feld als Gruppe ausgewählt wird, wird vor dem Sortieren gruppiert.

Wenn die Drag-and-Drop-Sortierung in einem Tabellenblock aktiviert wird, muss das Sortierfeld ausgewählt werden.

Beim Erstellen eines Kanban-Blocks muss das Sortierfeld ausgewählt werden.

Anpassung der Benutzer- und Berechtigungsoberflächen

Eine Benutzerverwaltungsoberfläche wurde hinzugefügt und die Benutzer- und Rollenverwaltung unter einem Menü zusammengefasst.

Die Rollenverwaltungsoberfläche wurde angepasst, um die Verwaltung von benutzerassoziierten Rollen, Berechtigungen, Abteilungen usw. zu erleichtern.

Die ursprünglichen „Aktionsberechtigungen“ wurden auf die Registerkarte „Datenquelle“ verschoben.

Abteilungs-Plugin

Organisieren Sie Benutzer nach Abteilungen, legen Sie hierarchische Beziehungen fest, verknüpfen Sie Rollen zur Steuerung von Berechtigungen und verwenden Sie Abteilungen als Variablen in Workflows und Ausdrücken.

Workflow: Genehmigung

Das Genehmigungs-Plugin bietet spezielle Workflow-Typen (Trigger) „Genehmigung starten“ und „Genehmigungs“-Knoten für diesen Prozess. In Kombination mit den einzigartigen benutzerdefinierten Datentabellen und benutzerdefinierten Blöcken von NocoBase können verschiedene Genehmigungsszenarien schnell und flexibel erstellt und verwaltet werden.

Genehmigungskonfiguration

Genehmigungskonfiguration

Genehmigungsprozess

Genehmigungsprozess

Weitere Details finden Sie in der Dokumentation: Workflow-Genehmigung

Workflow: Prozess beenden-Knoten

Dieser Knoten beendet die aktuelle Ausführung des Workflows sofort, wenn er ausgeführt wird, und endet mit dem im Knoten konfigurierten Status. Er wird typischerweise für die Steuerung spezifischer Logikabläufe verwendet, um den aktuellen Workflow nach Erfüllung bestimmter logischer Bedingungen zu verlassen, ohne mit der nachfolgenden Verarbeitung fortzufahren. Er kann mit dem return-Befehl in Programmiersprachen verglichen werden, der verwendet wird, um die aktuell ausgeführte Funktion zu verlassen.

Weitere Details finden Sie in der Dokumentation: Prozess beenden-Knoten

Workflow: Benutzerdefinierter Variablenknoten

Variablen können im Workflow deklariert oder zuvor deklarierten Variablen Werte zugewiesen werden, typischerweise um temporäre Daten im Workflow zu speichern. Er eignet sich für Szenarien, in denen Berechnungsergebnisse für die spätere Verwendung außerhalb des Zweigs (z. B. Schleifen, Parallelität usw.) gespeichert werden müssen.

Weitere Details finden Sie in der Dokumentation: Benutzerdefinierter Variablenknoten

Workflow: Request Interceptor

Das Request Interceptor-Plugin bietet einen Mechanismus zum Abfangen von Operationen auf Formularen, wobei das Abfangereignis ausgelöst wird, nachdem die entsprechende Formularoperation übermittelt und bevor sie verarbeitet wird. Wenn im nachfolgenden Prozessablauf nach dem Auslösen ein „Prozess beenden“-Knoten ausgeführt wird oder andere Knoten nicht ausgeführt werden (Fehler oder andere unvollständige Ausführungen), wird die Formularoperation abgefangen, andernfalls wird die geplante Operation normal ausgeführt. Es kann für Geschäftsvalidierungen oder Logikprüfungen verwendet werden, um vom Client übermittelte Erstellungs-, Aktualisierungs- und Löschoperationen zu genehmigen oder abzufangen.

Weitere Details finden Sie in der Dokumentation: Request Interceptor

Workflow: Antwortnachricht-Knoten

Der Antwortnachricht-Knoten wird verwendet, um dem Client in bestimmten Arten von Workflows (z. B. Request Interception und Formularereignisse) Feedback mit benutzerdefinierten Nachrichten zu geben.

Knotenkonfiguration

Hinweismeldung

Weitere Details finden Sie in der Dokumentation: Antwortnachricht-Knoten

Inkompatible Änderungen

APIs mit Namenskonflikten

In dieser Kernel-Änderung stehen einige neue Versionen von APIs im Konflikt mit den Namen der alten Version. Diese in Konflikt stehenden alten Versionen von APIs werden in dieser Version beibehalten, jedoch einheitlich mit dem Suffix _deprecated versehen.

Ursprüngliche APIVeraltete APINeue API
CollectionProviderCollectionProvider_deprecatedCollectionProvider
useCollectionuseCollection_deprecateduseCollection
useCollectionFielduseCollectionField_deprecateduseCollectionField
useCollectionManageruseCollectionManager_deprecateduseCollectionManager
useContext(CollectionManagerContext)useCollectionManager_deprecateduseCollectionManager

Wenn Sie die oben genannten zugehörigen APIs verwenden, haben Sie zwei Möglichkeiten zur Änderung:

  • Einfacher Austausch: Ersetzen Sie die ursprüngliche API durch die mit dem Suffix _deprecated, z. B. ersetzen Sie useCollection() durch useRecord_deprecated().
  • Verwenden Sie die neue API gemäß der neuen Dokumentation: Obwohl die Namen der neuen APIs mit den alten APIs identisch sind, gibt es Unterschiede bei Parametern und Rückgabewerten. Sie müssen die neue Dokumentation konsultieren, um den entsprechenden Code anzupassen.

Andere APIs, die angepasst werden müssen

  • registerTemplate() geändert zu app.dataSourceManager.addCollectionTemplates()
  • registerField() geändert zu app.dataSourceManager.addFieldInterfaces()
  • registerGroup() geändert zu app.dataSourceManager.addFieldInterfaceGroups()
  • useContext(CollectionManagerContext) geändert zu useCollectionManager_deprecated()
  • Erweitern Sie Collections mit ExtendCollectionsProvider
  • RecordProvider erfordert die explizite Übergabe des parent-Parameters, wenn nötig

Änderungsbeispiele

Erweiterung der Collection-Vorlage

Definition

Zuvor als Objekt definiert, muss es jetzt in eine Klasse geändert werden. Beispiel:

Vorher:

import { ICollectionTemplate } from '@nocobase/client';

const calendar: ICollectionTemplate = {
  name: 'calendar',
  title: 'Calendar collection',
  order: 2,
  color: 'orange',
  // ...
}

Jetzt:

import { CollectionTemplate } from '@nocobase/client';

class CalendarCollectionTemplate extends CollectionTemplate {
  name = 'calendar';
  title = 'Calendar collection';
  order = 2;
  color = 'orange';
}

Die ursprünglichen Objekteigenschaften werden zu Klassenmitgliedern.

Registrierung

Zuvor über registerTemplate registriert, muss jetzt über die dataSourceManager.addCollectionTemplates des Plugins registriert werden. Beispiel:

Vorher:

import { registerTemplate } from '@nocobase/client';
import { calendar } from './calendar'

registerTemplate('calendar', calendar);

Jetzt:

import { Plugin } from '@nocobase/client';
import { CalendarCollectionTemplate } from './calendar'

export class CalendarPluginClient extends Plugin {
  async load() {
    this.app.dataSourceManager.addCollectionTemplates([CalendarCollectionTemplate]);
  }
}

Erweiterung des Feld-Interfaces

Definition

Zuvor als Objekt definiert, muss es jetzt in eine Klasse geändert werden. Beispiel:

Vorher:

import { IField } from '@nocobase/client';

const attachment: IField = {
  name: 'attachment',
  type: 'object',
  group: 'media',
  title: 'Attachment',
  // ...
}

Jetzt:

import { CollectionFieldInterface } from '@nocobase/client';

class AttachmentFieldInterface extends CollectionFieldInterface {
  name = 'attachment';
  type = 'object';
  group = 'media';
  title = 'Attachment';
  // ...
}

Die ursprünglichen Objekteigenschaften werden zu Klassenmitgliedern.

Registrierung

Zuvor über registerField registriert, muss jetzt über die dataSourceManager.addFieldInterfaces des Plugins registriert werden und erfordert keine erneute Übergabe von CollectionManagerProvider. Beispiel:

Vorher:

import { registerField } from '@nocobase/client';
import { attachment } from './attachment'

- registerField(attachment.group, 'attachment', attachment);

export const FileManagerProvider: FC = (props) => {
  return (
-   <CollectionManagerProvider interfaces={{ attachment }}>
      <SchemaComponentOptions scope={hooks} components={{ UploadActionInitializer }}>
        {props.children}
      </SchemaComponentOptions>
-   </CollectionManagerProvider>
  );
};

Jetzt:

import { Plugin } from '@nocobase/client';
import { AttachmentFieldInterface } from './attachment'

export class FilPlugin extends Plugin {
  async load() {
    this.app.dataSourceManager.addFieldInterfaces([AttachmentFieldInterface]);
  }
}

Erweiterung der Feld-Interface-Gruppe

Zuvor über registerGroup registriert, muss jetzt über die dataSourceManager.addFieldInterfaceGroups des Plugins registriert werden. Beispiel:

- import { registerGroup, Plugin } from '@nocobase/client';
+ import { Plugin } from '@nocobase/client';

- registerGroup('map', {
-        label: 'Map-based geometry',
-        order: 10
- })

export class MapPlugin extends Plugin {
  async load() {
+    this.app.dataSourceManager.addFieldInterfaceGroups({
+      map: {
+        label: generateNTemplate('Map-based geometry'),
+        order: 51,
+      },
+    });
  }
}

useContext(CollectionManagerContext) geändert zu useCollectionManager_deprecated()

- const ctx = useContext(CollectionManagerContext);
+ const ctx = useCollectionManager_deprecated();

Collections erweitern, ExtendCollectionsProvider anstelle von CollectionManagerProvider verwenden

const Demo = () => {
-  <CollectionManagerProvider collections={[apiKeysCollection]}>
+  <ExtendCollectionsProvider collections={[apiKeysCollection]}>
...
-  </CollectionManagerProvider>
+  </ExtendCollectionsProvider>
}

Änderungen an RecordProvider

Bisher wurde, wenn die parent-Eigenschaft nicht übergeben wurde, automatisch der Wert des letzten RecordProvider als parent abgerufen. Jetzt muss parent explizit übergeben werden, und wenn parent nicht übergeben wird, ist der Wert von parent undefined.

- <RecordProvider record={recordData}>
+ <RecordProvider record={recordData} parent={parentRecordData}>
...
</RecordProvider>

Wenn es keinen historischen Ballast gibt, können Sie auch direkt CollectionRecordProvider als Ersatz verwenden.

- <RecordProvider record={recordData}>
+ <CollectionRecordProvider record={recordData} parent={parentRecordData}>
...
- </RecordProvider>
+ </CollectionRecordProvider>

⚠️Unterschied zwischen RecordProvider und CollectionRecordProvider

  • RecordProvider ist veraltet und wird in Zukunft entfernt.
  • RecordProvider trägt den alten RecordContext, CollectionRecordProvider nicht.
× View Image