What we call the news

Profile of "Hawkes"

Dear visitor, welcome to Packageforge. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

Hawkes

Administrator
- "Hawkes" is male
- Register now!
You have to register first, to connect to this user.

Rating:

by Hawkes, Saturday, August 15th 2009, 11:22pm

Obwohl ich trotz meinem vorerst letztem Auftrag (ich hab gerade zeitlich nicht den Rahmen dafür), einem neuen Nebenjob und so trivialen Dingen wie meinem Studium nicht mit freier Zeit um mich werfen kann, habe ich in den letzten Tagen mit mehreren Entwicklern, auch mit WoltLab selber (also Marcel Werk) gesprochen, da ich es für notwendig erachte, dass das WCF eine einheitliche Schnittstelle für Benachrichtigungen und Neuigkeiten, die direkt den Benutzer individuell betreffen, eingeführt wird.

Meine Inspirationsquelle sind hierbei die Social Networks, die solche Systeme ja für ihren Inhalte integriert haben. D.h. geplant ist:

API für Benachrichtigungsobjekte und Benachrichtungsobjektypen
Sogenannte Notificationevents, d.h. es soll automatisch und manuell möglich sein, Events zu verwenden oder selber abzufeuer, um Benachrichtigungen an Benutzer zu übermitteln
NotificationMessages und NotificationTypes. Notification Messages sind an sich nur dynamische Sprachvariablen und ergeben sich aus den obigen Featurs. NotificationTypes sind Arten der Benachrichtigung, d.h. über das userPanel/userMessages, PN oder Mail bzw, generell dynamisch erweiterbare Systeme
Jeder Benutzer hat im Profil eine neue Optionsseite, um einstellen zu können, bei welchen NotificationEvents er benachrichtigt werden will und auf welche Art.

Längerfristig geplant:

WCF User Panel: MessageCenter mit genauer Übersicht der letzten Benachrichtigungen
WBB Plugin -> Anzeige über das userPanel im Header mit Ajax Dropdown

Einen Zeitplan kann und will ich momentan aber noch nicht nennen. Wenn es gut läuft bei meinen sonstigen ToDos, kann ich nächste Woche nebenbei beginnen. Wenn es etwas ordentliches wird, werde ich probieren zusätzlich zur Quellcodedoku auch eine extra Entwicklerdoku zu schreiben. Das System soll ja für Entwickler attraktiv sein. Es gibt auch ein detaillierteres Konzept, aber ich bin da sehr altmodisch, daher ist das nur auf einen Block aufgezeichnet bei mir und nicht "digitalisiert"

Für weitere Kommentare oder ernsthafte (wenn jemand mitentwickeln oder planen möchte, sollte derjenige sich sehr sehr gut mti dem WCF und den dort verwendeten Konzepten, sowie dem WCF 1.1 im speziellen auskennen) Mitarbeit, bin ich gerne offen.

PS: Der Titel spielt auf dieses Video an: http://sendables.jibjab.com/originals/what_we_call_the_news

This article has been read 1,709 times.

Tags: API, Framework, Notification, Schnittstelle, WCF

Categories: Community Framework, Notification API

Rate this article

Comments (8)

8

by Hawkes (Sunday, August 23rd 2009, 4:39pm)

Ich bin schlecht im Visualisieren, daher beschreibe ich es nochmal, wie die Grundzüge der API momentan aufgebaut werden:

Ein Benutzer interagiert mit einer Form oder Action, die wiederum ein bestimmtes Objekt (NotificationObject) je nach Benutzerinteraktion manipuliert. Falls für dieses Objekt sog. NotificationEvents (zum Beispiel ein neuer Gästebucheintrag wäre saved@UserGuestBookEntryAddForm) existieren, wird ein genereller NotificationHandler aufgerunfen. Dies ist eine generelle Handlerclass, die aber das Interface EventListener implementiert und damit gleichzeitig als EventListener im WCF-Sinne fungiert. Dieser Handler guckt nun, ob und auf welche Weise der Empfänger, der Benachrichtigung, die durch dieses Event ausgelöst wird, benachrichtigt werden soll und instanziiert den entsprechenden NotificationType (dies sind als Standard infobox/usermessages, pn, mail und twitter direct message). Der NotificationType holt sich nun durch übermittel des NotificationObjects an die entsprechenden NotificationObjectType class den für sich passende Benachrichtigungstext. Nun wird die Benachrichtigung noch in der DB geloggt, sodass sie später über ein Kontrollzentrum wieder abrufbar bzw. wiedererstellbar ist. Gleichzeitig wird sie, falls nötig, geched gespeichert, um Rechenzeit zu sparen. Die ganzen Detailunterschiede übernehmen dann die NotificationTypes. Der userMessages NotificationType ist der komplexeste und auch der, wo am meisten Optimierung nötig ist.

Generell soll diese API eben nicht nur die Möglichkeit bieten alle bisherigen Benachrichtigungen zu vereinheitlichen (Abonnements, PNs, Verwarnungen, Gästebucheinträge, Bewertungen, u.v.m.), sondern auch um neue Benachrichtigungsarten und Objekte erweiterbar sein.
7

by black_kite (Saturday, August 22nd 2009, 11:56pm)

habe mir auch schon mal so was überlegt auf den Papier, das eine globale box genutzt wird die datenbank prüft und nach typs sortiert und dieses ausgibt, aber da ich doch sehr beschränkt in den Bereich bin würde es mit Sicherheit Jahre dauern bis ich was funktions- fähiges habe, bin ja froh das ich paar EL und tpls ändern kann für meine bedürfnisse
6

by Hawkes (Thursday, August 20th 2009, 7:35pm)

ein wcf modul, kein plugin. plugin != paket
5

by MysteryForce (Thursday, August 20th 2009, 9:38am)

Hawkes, ich weiß nicht, ob es jetzt das ist, was ich auch mal entwickeln wollte, aber sind das so Nachrichten wie bei neuen PNs? Dass sich nicht jedes Plugin einzeln im userMessages-Platzhalter einnistet, sondern dies von Deinem Plugin erledigt wird?
4

by Hawkes (Thursday, August 20th 2009, 12:53am)

An sich schon positiv, aber eben als [langfristig geplant] Die Jungs haben ja einige Baustellen. Ich brauch ein flexibles Benachrichtigungssystem eher auch selber für etwaige zukünftige Entwicklungen, aber auch das Renommeesystem.
3

by Xtreme (Wednesday, August 19th 2009, 5:02pm)

mich würde ja mal interessieren wie marcel werk auf deinen vorschlag reagiert hat, was die dazu gesagt haben?
2

by Hawkes (Wednesday, August 19th 2009, 12:46am)

Es soll eine API werden, die dann LGPL sein soll. Es soll ja auch anderen Entwicklern helfen.

Da das 3.1 mit mehr als 2 Jahren doch recht lange auf sich hat warten lassen, will ich hier etwas zuvorkommen, da ich es für eigene Entwicklungen brauche. Außerdem wäre es bei LGPL ja möglich, solange ich WoltLabs Codequalitätsanforderungen erfülle, dass sie ihre Entwicklung auf Basis meiner machen oder zumindest eine Teilkompatibilität herstellen.
1

by black_kite (Sunday, August 16th 2009, 8:15pm)

hört sich gut an, aber soll sowas nicht mit den 3.2 kommen? abgesehen davon Pay oder free?

bin aber auch der meinung sowas muss es geben zumal es jetzt Blog, galerie und Gästebuch gibt wo man gerne drüber informiert werden möchte wenn was neu ist. abgeshen davon kann man das system ja dan auch Abo mäßig nutzen und beistimte benutzer Abonieren um zu sehen ah er hat neuen blog eintrag geschrieben.