Empfohlener Ersatz für modifyClass("model:composer") beim Überschreiben von save()

Entwickler
1

Ich migriere weg von der veralteten api.modifyClass("model:composer", ...).

Mein aktueller Override von Composer#save ändert das Speicherverhalten bedingt, muss aber ansonsten super.save(opts) aufrufen.

Ich sehe die neuen addModelMethod / addModelCallback APIs, aber ich finde kein Beispiel im Core, das zeigt, wie addModelMethod verwendet wird, um eine bestehende Methode zu überschreiben und gleichzeitig Zugriff auf die ursprüngliche Implementierung zu behalten.

Ist addModelMethod für das Überschreiben bestehender Modellmethoden wie dieser gedacht? Wenn ja, wie sollte ein Plugin an die ursprüngliche save()-Implementierung delegieren?

Oder gibt es einen anderen Erweiterungspunkt, der für diesen Composer-Fall verwendet werden sollte?

2

Ich nehme an, das hängt davon ab, was du mit dem Überschreiben der save-Methode erreichen möchtest…

Wenn du das Speichern basierend auf einer bestimmten Bedingung verhindern möchtest, könntest du unseren composer-service-cannot-submit-post Value Transformer verwenden.

Wenn du etwas tun möchtest, sobald der Beitrag erstellt wurde, gibt es api.onAppEvent("post:created").

Wenn du ein Feld hinzufügst, gibt es api.serializeOnCreate.

Passt eine dieser Optionen zu dem, was du suchst?

3

Danke! Ich verwende bereits composer-service-cannot-submit-post — es verarbeitet die prüfung auf Dienstebene. Aber das save() des Composer-Modells überprüft ebenfalls cantSubmitPost, was missingReplyCharacters > 0 einschließt, sodass ein leerer Textkörper dort weiterhin blockiert wird.

onAppEvent("post:created") ist zu spät, da der Beitrag niemals erstellt wird, und serializeOnCreate fügt nur Felder zur Anfrage hinzu, was bei der Validierung der Textkörperlänge nicht hilft.

Das verbleibende Problem ist also, missingReplyCharacters / cantSubmitPost für den ersten Beitrag zu umgehen. Gibt es dafür einen unterstützten Erweiterungspunkt?

Hier ist der aktuelle Initializer zur Referenz:

4

@david, ich würde mich über jeden Input freuen, den du zum besten Vorgehen hier haben könntest.

5

Am besten wäre es, einen neuen Hook in den Discourse-Core hinzuzufügen, mit dem du auf unterstützte Weise das erreichen kannst, was du brauchst. Wie wäre es mit etwas in dieser Art:

Dann würde dein Plugin so aussehen:

api.registerValueTransformer(
  "composer-minimum-post-length",
  ({ value, context: { composer } }) => {
    if (
      composer.siteSettings.discourse_optional_topic_body_enabled &&
      composer.topicFirstPost
    ) {
      return 0;
    }

    return value; // Kernlogik beibehalten
  }
);

Sag Bescheid, ob das für deinen Anwendungsfall funktioniert, dann nehme ich den PR aus dem Entwurfsmodus und kann ihn reviewen/mergen lassen.

6

Danke, David! Ich habe den composer-minimum-post-length-Transformer getestet und er funktioniert — Themen mit leeren Inhalten werden erfolgreich erstellt.

Eine Sache, die mir aufgefallen ist: Der Editor zeigt weiterhin „Post can’t be empty“ an, da die validation in composer-editor eine hartkodierte replyLength < 1-Prüfung enthält, die minimumPostLength nicht berücksichtigt.

Könnte diese Prüfung den Transformer ebenfalls berücksichtigen oder übersprungen werden, wenn minimumPostLength auf 0 gesetzt ist?

7

Klingt gut – in den PR aufgenommen :+1:

9

Funktioniert jetzt einwandfrei. Vielen Dank, dass du das hinzugefügt hast, @david! :raising_hands: