Event für notificationList

  • Es wäre schön, wenn die Templates (ab 5.2) notificationList und notificationListUserPanel um ein Event erweitert würden, welches man nutzen kann, um dort z.B. ein zusätzliches data-Attribut hinzufügen zu können. Aktuell lassen sich nämlich leider nur bereits gelesene Benachrichtigungen mühevoll anhand der Ziel-URL (data-url) voneinander unterscheiden. Bis dahin kann man maximal irgendwie mit dem Text arbeiten, das ist halt auch maximal bescheiden.

  • Es geht nicht darum zu ermitteln, ob eine Benachrichtigung gelesen wurde, oder nicht, sondern darum, spezifische Benachrichtigungen erkennen zu können. Das geht aktuell nur, wenn die Benachrichtigungen gelesen wurden, weil erst dann der "echte" Link im data-url-Attribut steht.

  • In meinem speziellen Fall wären objectType und auch additionalData von Interesse, weil ich ersteres nutzen kann, um überhaupt zu erkennen, woher die Benachrichtigung kommt und letzteres, um eventuell zusätzliche gespeicherte Informationen zu einer Benachrichtigung verarbeiten zu können. Daher der Vorschlag, (dem li) ein Event zu spendieren. Oder zwei zusätzliche data-Attribute hinzufügen, aus denen man diese Informationen entnehmen kann, also z.B:


    Code
    data-object-type="{@$notification[event]->getNotification()->objectType}" data-additional-data="{$notification[event]->getNotification()->additionalData|json_encode}"


    oder dergleichen.

  • In meinem konrekten Fall:


    Eine unserer Erweiterungen versendet Benachrichtigungen ohne UserID, also als Gast. Im Normalfall führt das halt dazu, dass dann ein Avatar mit der Aufschrift "GA" angezeigt wird. Viele unserer Kunden wünschen sich aber, diese Anzeige zu verändern, allerdings möchten wir zu diesem Zweck ungerne einen Benutzer verknüpfen, der diese Benachrichtigungen versendet, sondern weiterhin mit dem Gast-Benutzer arbeiten, aber halt die Möglichkeit nutzen, den Avatar verändern zu können. Das funktioniert auch grundsätzlich, aber nur dann, wenn die Benachrichtigung gelesen wurde, weil erst danach der eigentliche Link zur Verfügung steht.


    Tatsächlich würde es mir schon reichen, wenn in jedem Fall (also egal ob gelesen, oder ungelesen) die "echte" Ziel-URL als Data-Attribut zur Verfügung stünde. Die benötigten Informationen kann ich mir selbst aus der URL nudeln. Ergo:


    Code
    data-link="{if $notification[event]->isConfirmed()}{$notification[event]->getLink()}{else}{link controller='NotificationConfirm' id=$notification[notificationID]}{/link}{/if}"


    =>


    Code
    data-link="{if $notification[event]->isConfirmed()}{$notification[event]->getLink()}{else}{link controller='NotificationConfirm' id=$notification[notificationID]}{/link}{/if}" data-event-link="{$notification[event]->getLink()}"
    • Official Post

    Das ist ziemlich fragil. Die Verwendung eines "System-Benutzer" wäre hier deutlich sinnvoller, statt hier irgendwie per Magie das Avatar auszutauschen. Ein entsprechendes Konto sollte man nicht um jeden Preis vermeiden, das führt nur zu solchen seltsamen Verrenkungen. Gleichzeitig eröffnet das Benutzerkonto entsprechende Möglichkeiten zur Individualisierung (Benutzername, Avatar), ohne hier künstlich Redundanzen zu schaffen.

  • Letztlich ist das nur ein möglicher Anwendungsfall. Vielleicht will ich einfach (ungelesene) Benachrichtigungen aus dem Artikelsystem rot umranden?

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!