Nachrichtensystem

Dieser Bereich dient dazu, eure Tricks und Erweiterungen vorzustellen, damit diese auch andere Anwender nutzen können. // This area can be used to publish your tricks and extensions to the APF to be used by other developers.
Benutzeravatar
Screeze
Beiträge: 1920
Registriert: 05.08.2009, 09:49:04
Kontaktdaten:

Re: Nachrichtensystem

Beitrag von Screeze » 27.04.2011, 12:35:42

Ich hab eben noch einen kleinen Fehler ausgebessert: Das nachträgliche hinzufügen neuer Empfänger zu einem Channel hat nicht korrekt funktioniert.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4527
Registriert: 04.11.2007, 16:13:53

Re: MessageModule

Beitrag von dr.e. » 09.05.2011, 22:40:03

Hallo Ralf,

hier mein Feedback:
  • Config sollte unter /config/extensions/postbox liegen
  • abstractdomainobjects liegt in einer tieferen Struktur als die DOs selbst. Das muss hinsichtlich
    der Abhängigkeit in einem Package umgekehrt sein.
  • Mit den Namen "serviceobjects" haben wir eine Überlagerung der Namen für ServiceManager und GORM.
    Das sollten wir insoweit auflösen, als dass die GORM-Config "domainobjects" heißt.
  • Ein paar Dateien haben Leerzeilen am Ende (--> cannot send header information ...)
  • Für die Erstellung von entsprechenden DOs sollten wir vielleicht eine generische Factory haben,
    die per DI schon den GORM kennt und dann ein entsprechendes DO liefert. Ansonsten musst du immer
    den GORM manuell injizieren (siehe PostboxFactory, Postbox).
  • Für Postbox brauchen wir eine Factory - klar -, jedoch sollte man trotzdem die Postbox per DI
    erzeugen und dort hinein den GORM injitieren. Die PostboxFactory an sich braucht den GORM ja nicht.
  • Warum hat die Klasse PostboxFolder einen Konstruktor? Das wäre doch bei Vererbung von PostboxFolderBase
    nicht notwendig
  • Der GORM kann ab 1.14 nun auch direkt erzeugt werden - ohne Zwischenschritt über GenericORMapperDIConfiguration.
Ich werde nun noch die Wiki-Seite reviewen und dir ein paar Zeilen schreiben.

Edit: ich habe noch ein paar Dinge gefunden, melde mich also nochmal mit etwas mehr Text die Tage.
Viele Grüße,
Christian

Benutzeravatar
Screeze
Beiträge: 1920
Registriert: 05.08.2009, 09:49:04
Kontaktdaten:

Re: Nachrichtensystem

Beitrag von Screeze » 10.05.2011, 21:37:46

Ich hab deinen Beitrag mal in den Richtigen thread geschoben, du hast auf meine ganz alte nachrichtenerweiterung geantwortet, die nie ins APF eingezogen ist, hab das andere thema mal gesperrt und einen Link hierher gesetzt.
Config sollte unter /config/extensions/postbox liegen
Stimmt, das hab ich vergessen zu verschieben, wird nachgeholt.
abstractdomainobjects liegt in einer tieferen Struktur als die DOs selbst. Das muss hinsichtlich
der Abhängigkeit in einem Package umgekehrt sein.
Hmm dann würde ich einfach alle in den selben Ordner stecken, hatte das eigentlich nur untergeordnet um die basis-objekte in den "hintergrund" zu stellen damit niemand auf die Idee kommt dort drin rumzuwerkeln ;)
Mit den Namen "serviceobjects" haben wir eine Überlagerung der Namen für ServiceManager und GORM.
Das sollten wir insoweit auflösen, als dass die GORM-Config "domainobjects" heißt.
Dann müssen wir nochmal an den GORM an, aber leuchtet ein.
Für die Erstellung von entsprechenden DOs sollten wir vielleicht eine generische Factory haben,
die per DI schon den GORM kennt und dann ein entsprechendes DO liefert. Ansonsten musst du immer
den GORM manuell injizieren (siehe PostboxFactory, Postbox).
Wenn ich das jetzt richtig verstanden habe, verkompliziert das aber die Anwendung? d.h. ich muss mir immer eine factory beziehen, wenn ich ein neues objekt, das ein DO ist, erzeugen will? Da wäre ich absolut dagegen...
Für Postbox brauchen wir eine Factory - klar -, jedoch sollte man trotzdem die Postbox per DI
erzeugen und dort hinein den GORM injitieren. Die PostboxFactory an sich braucht den GORM ja nicht.
Einverstanden.
Warum hat die Klasse PostboxFolder einen Konstruktor? Das wäre doch bei Vererbung von PostboxFolderBase
nicht notwendig
Das hab ich bei allen gemacht, da ich nicht sicher bin ob auch ein __construct() korrekt vererbt wird? Hatte da mal einen Fall, bei dem das nicht der Fall zu sein schien, ist aber eine Weile her. Kann ich das weglassen?
Der GORM kann ab 1.14 nun auch direkt erzeugt werden - ohne Zwischenschritt über GenericORMapperDIConfiguration.
Den Punkt hab ich nicht ganz verstanden, kannst du das genauer erläutern?
Edit: ich habe noch ein paar Dinge gefunden, melde mich also nochmal mit etwas mehr Text die Tage.
Alles klar, lass dir Zeit ;) Ich kann eh nicht sagen wann ich die Änderungen machen kann, ist momentan alles etwas knapp bei mir, aber ich versuch mein Bestes ;)

Benutzeravatar
dr.e.
Administrator
Beiträge: 4527
Registriert: 04.11.2007, 16:13:53

Re: Nachrichtensystem

Beitrag von dr.e. » 14.05.2011, 11:46:13

Hi Ralf,

danke für's Verschieben, ich hatte das im Nachgang auch bemerkt, dass der Post da nicht ganz zum Thread passte. :D

Zunächst meine Statements:
Hmm dann würde ich einfach alle in den selben Ordner stecken, hatte das eigentlich nur untergeordnet um die basis-objekte in den "hintergrund" zu stellen damit niemand auf die Idee kommt dort drin rumzuwerkeln ;)
Das ist eben genau nicht richtig. :)
Dann müssen wir nochmal an den GORM an, aber leuchtet ein.
OK. Übernimmst du das? Sollte hinsichtlich der Änderung nicht tragisch sein; die Doku ist ja noch nicht geschrieben. ;)
Wenn ich das jetzt richtig verstanden habe, verkompliziert das aber die Anwendung? d.h. ich muss mir immer eine factory beziehen, wenn ich ein neues objekt, das ein DO ist, erzeugen will? Da wäre ich absolut dagegen...
Das wäre die Idee gewesen. Inwieweit verkompliziert das die Anwendung?
Das hab ich bei allen gemacht, da ich nicht sicher bin ob auch ein __construct() korrekt vererbt wird? Hatte da mal einen Fall, bei dem das nicht der Fall zu sein schien, ist aber eine Weile her. Kann ich das weglassen?
Dachte schon. :roll: Falls nicht, muss das natürlich hin.
Den Punkt hab ich nicht ganz verstanden, kannst du das genauer erläutern?
Du nutzt die GenericORMapperConfiguration als Service, den du dem GORM per DI injizierst. Das geht einfacher auch so: http://wiki.adventure-php-framework.org ... figuration.

Hier die weiteren Punkt zum Test-Package:
  • newfolder_controller: warum wird die Validierungs-Message in einen Platzhalter geschrieben und
    nicht ein <form:error/> oder <form:listener /> genutzt?
  • newfolder_controller: appendCssClass('apf-form-error') kann durch
    appendCssClass(AbstractFormValidator::$DEFAULT_MARKER_CLASS) ersetzt werden.
  • newfolder_controller: html_entity_decode(trim()) kann durch Formular-Filter abgedeckt werden.
Ist aber noch immer nicht alles. :) Was ich grundsätzlich an den Sourcen im SVN vermisse, ist eine relativ nackte Beispiel-Implementierung für die GUI. Das würde insbesondere die Anwendung sehr vereinfachen und es wäre eine Option das als Demo in die Sandbox einzubauen. Was denkst du? Falls du einverstanden bist, würde ich mich auch daran beteiligen, das auf Basis deines Test-Packages aufzusetzen.
Viele Grüße,
Christian

Benutzeravatar
Screeze
Beiträge: 1920
Registriert: 05.08.2009, 09:49:04
Kontaktdaten:

Re: Nachrichtensystem

Beitrag von Screeze » 14.05.2011, 13:33:16

Das ist eben genau nicht richtig. :)
Was genau ist nicht richtig? Das alles in einen Ordner zu setzen, oder die momentane Unterteilung?
OK. Übernimmst du das? Sollte hinsichtlich der Änderung nicht tragisch sein; die Doku ist ja noch nicht geschrieben. ;)
Wenn ich das mache kann ich aber nicht verspreche dass ich alles vor dem 3.6. schaffe, an dem Tag ist meine letzte Abiprüfung... Aber spätestens die Tage danach hab ich Zeit mich an die Aufgaben zu setzen.

Das wäre die Idee gewesen. Inwieweit verkompliziert das die Anwendung?
Ich bin ehrlich gesagt kein Fan von vielen Factories, ein $a = new b(); ist halt deutlich schneller geschrieben, bei Factories muss ich dann immer schaun welchen Namespace die haben etc...
Dachte schon. :roll: Falls nicht, muss das natürlich hin.
Hmm ich werd's bei Gelegenheit einfach noch einmal ausprobieren ;)
Du nutzt die GenericORMapperConfiguration als Service, den du dem GORM per DI injizierst. Das geht einfacher auch so: http://wiki.adventure-php-framework.org ... figuration.
Ah ok habs glaub ich verstanden, du beziehst dich dabei aber auf das TestPackage oder? in der normalen Extension wird der GORM ja nirgends direkt bezogen.
newfolder_controller: warum wird die Validierungs-Message in einen Platzhalter geschrieben und
nicht ein <form:error/> oder <form:listener /> genutzt?
Ich wusste bis vor kurzem nicht, dass innerhalb eines <form:error /> auch ein Placeholder unterstützt wird, weshalb ich das als Workaround benutzt habe öfter. Warum ich das hier allerdings gemacht habe, wo doch sowieso nur eine einzige Meldung möglich ist, weiß ich gerade selbst nicht mehr :? :?
newfolder_controller: appendCssClass('apf-form-error') kann durch
appendCssClass(AbstractFormValidator::$DEFAULT_MARKER_CLASS) ersetzt werden.
Stimmt, ist besser so.
newfolder_controller: html_entity_decode(trim()) kann durch Formular-Filter abgedeckt werden.
Ich denke du meinst den newchannel_controller, und hier sage ich: NEIN! ;)
Denn: es wird hier nicht maskiert(html_entities()), sondern die Maskierung des Standard-Input Filters aufgehoben(html_entity_decode()), weil ich keine kodierten Werte in der Datenbank haben will sondern Plaintext (die Diskussion hatten wir ja kürzlich schon ;)). Und nur das trim() wollte ich nicht extra als Filter abbilden ;)
Was ich grundsätzlich an den Sourcen im SVN vermisse, ist eine relativ nackte Beispiel-Implementierung für die GUI. Das würde insbesondere die Anwendung sehr vereinfachen und es wäre eine Option das als Demo in die Sandbox einzubauen. Was denkst du? Falls du einverstanden bist, würde ich mich auch daran beteiligen, das auf Basis deines Test-Packages aufzusetzen.
Ich hatte ja angedacht das Testpackage in die Sandbox zu integrieren später, aber wenn du das mit ins SVN setzen willst, gerne. Wenn du das übernehmen könntest, wäre das super momentan. Dann kannst du am besten auch gleich die Änderungen die nur das Testpackage betreffen selbst dort umsetzen, wenn das danach eh hinfällig wird. :)

Benutzeravatar
dr.e.
Administrator
Beiträge: 4527
Registriert: 04.11.2007, 16:13:53

Re: Nachrichtensystem

Beitrag von dr.e. » 14.05.2011, 13:51:07

Hallo Ralf,
Was genau ist nicht richtig? Das alles in einen Ordner zu setzen, oder die momentane Unterteilung?
Die Unterteilung der Ordner bezogen auf die Abhängigkeits-Hierarchie.
Wenn ich das mache kann ich aber nicht verspreche dass ich alles vor dem 3.6. schaffe, an dem Tag ist meine letzte Abiprüfung... Aber spätestens die Tage danach hab ich Zeit mich an die Aufgaben zu setzen.
No stress, please! :geek: Abi hat Vorrang, sowie Rechts- vor Links-Abbiegern. :D Ich kann ja schon mal die Anpassung der Konfigurations-Namen einbauen.
Ich bin ehrlich gesagt kein Fan von vielen Factories, ein $a = new b(); ist halt deutlich schneller geschrieben, bei Factories muss ich dann immer schaun welchen Namespace die haben etc...
Das ist korrekt, nur die Abhängigkeit zum GORM hätten wir weg. Wobei man diesen per DI ja sehr elegant injizieren kann. :roll: Hmm, lassen wir das mal einfach stehen.
Ah ok habs glaub ich verstanden, du beziehst dich dabei aber auf das TestPackage oder? in der normalen Extension wird der GORM ja nirgends direkt bezogen.
Genau. Der zweite Satz an Punkten bezieht sich ausschließlich auf das Test-Package.
Ich wusste bis vor kurzem nicht, dass innerhalb eines <form:error /> auch ein Placeholder unterstützt wird, weshalb ich das als Workaround benutzt habe öfter. Warum ich das hier allerdings gemacht habe, wo doch sowieso nur eine einzige Meldung möglich ist, weiß ich gerade selbst nicht mehr :? :?
Egal das können wir ja beim neuen Beispiel-Setup für die Extension mitnehmen.
Ich denke du meinst den newchannel_controller, und hier sage ich: NEIN! ;)
Denn: es wird hier nicht maskiert(html_entities()), sondern die Maskierung des Standard-Input Filters aufgehoben(html_entity_decode()), weil ich keine kodierten Werte in der Datenbank haben will sondern Plaintext (die Diskussion hatten wir ja kürzlich schon ;)). Und nur das trim() wollte ich nicht extra als Filter abbilden ;)
Der Standard-Filter codiert doch aber garnicht mehr. :D Gegen trim() alleine habe ich auch nix. Wobei ich natürlich zu deiner Verteidigung sagen muss, dass das Package auf 1.13 basiert. :D
Ich hatte ja angedacht das Testpackage in die Sandbox zu integrieren später, aber wenn du das mit ins SVN setzen willst, gerne. Wenn du das übernehmen könntest, wäre das super momentan. Dann kannst du am besten auch gleich die Änderungen die nur das Testpackage betreffen selbst dort umsetzen, wenn das danach eh hinfällig wird. :)
Das kann ich gerne übernehmen. Würde nur gerne für 1.14 das Thema Login/Umgt-Erweiterung höher priorisieren, damit man dort auch etwas zeigen kann. Das Test-Package braucht das ja ebenfalls.
Viele Grüße,
Christian

Benutzeravatar
Screeze
Beiträge: 1920
Registriert: 05.08.2009, 09:49:04
Kontaktdaten:

Re: Nachrichtensystem

Beitrag von Screeze » 14.05.2011, 13:58:32

Alles klar, dann sind wir uns soweit ja erst mal einig ;)

Benutzeravatar
Screeze
Beiträge: 1920
Registriert: 05.08.2009, 09:49:04
Kontaktdaten:

Re: Nachrichtensystem

Beitrag von Screeze » 04.06.2011, 18:28:53

Bin gerade beim Abarbeiten der Punkte, noch ist nichts im SVN, aber bereits erledigt habe ich:
  • Config sollte unter /config/extensions/postbox liegen
  • Mit den Namen "serviceobjects" haben wir eine Überlagerung der Namen für ServiceManager und GORM. Das sollten wir insoweit auflösen, als dass die GORM-Config "domainobjects" heißt.
  • Ein paar Dateien haben Leerzeilen am Ende (--> cannot send header information ...)
abstractdomainobjects liegt in einer tieferen Struktur als die DOs selbst. Das muss hinsichtlich
der Abhängigkeit in einem Package umgekehrt sein.
Die habe ich jetzt alle in den selben Ordner verschoben, ich möchte die DOs nicht tiefer setzen da sonst doch jemand auf die Idee kommt die abstractdomainobjects zu bearbeiten evtl., weil er die anderen gar nicht sieht.
Für Postbox brauchen wir eine Factory - klar -, jedoch sollte man trotzdem die Postbox per DI
erzeugen und dort hinein den GORM injitieren. Die PostboxFactory an sich braucht den GORM ja nicht.
Auch soweit erledigt, die Factory wird ab sofort nicht mehr per DI bezogen, sie bezieht stattdessen die Postbox per DI.
Jedoch fände ich es fast einfacher GANZ auf die Factory zu verzichten, da diese jetzt nur noch ein User Objekt entgegennimmt und der Postbox weiterreicht.
Dies könnte auch über eine statische Methode in der Postbox gelöst werden: "Postbox::getByUser($User)" Diese erzeugt ein Objekt vom Typ Postbox und übergibt dieser den User als Konstruktor, und gibt diese anschließend zurück (wie es bei Url::getFromString() z.B. bereits gemacht wird). Ist Performance- wie Handhabungstechnisch besser, meiner Ansicht nach. Was sagst du dazu?


Folgende Frage aber zu:
Der GORM kann ab 1.14 nun auch direkt erzeugt werden - ohne Zwischenschritt über GenericORMapperDIConfiguration.
Wie lassen sich mit dieser Lösung zusätzliche Konfigurationsdateien angeben?

Benutzeravatar
dr.e.
Administrator
Beiträge: 4527
Registriert: 04.11.2007, 16:13:53

Re: Nachrichtensystem

Beitrag von dr.e. » 04.06.2011, 21:41:47

Hi Ralf,
Auch soweit erledigt, die Factory wird ab sofort nicht mehr per DI bezogen, sie bezieht stattdessen die Postbox per DI.
Jedoch fände ich es fast einfacher GANZ auf die Factory zu verzichten, da diese jetzt nur noch ein User Objekt entgegennimmt und der Postbox weiterreicht.
Wenn du die Factory komplett los wirst um so besser.
Dies könnte auch über eine statische Methode in der Postbox gelöst werden: "Postbox::getByUser($User)" Diese erzeugt ein Objekt vom Typ Postbox und übergibt dieser den User als Konstruktor, und gibt diese anschließend zurück (wie es bei Url::getFromString() z.B. bereits gemacht wird). Ist Performance- wie Handhabungstechnisch besser, meiner Ansicht nach. Was sagst du dazu?
Das sehe ich auch so, damit hast du deine Factory als abstract factory schon korrekt verabreitet.
Wie lassen sich mit dieser Lösung zusätzliche Konfigurationsdateien angeben?
Das geht mit den GenericORMapperDIMappingConfiguration- und GenericORMapperDIRelationConfiguration-Klassen. Diese können als eigene Services erzeugt werden und dann dem GORM hinzugefügt werden. Siehe http://wiki.adventure-php-framework.org ... gurationen und http://wiki.adventure-php-framework.org ... gurationen.
Viele Grüße,
Christian

Benutzeravatar
Screeze
Beiträge: 1920
Registriert: 05.08.2009, 09:49:04
Kontaktdaten:

Re: Nachrichtensystem

Beitrag von Screeze » 04.06.2011, 22:36:00

Das sehe ich auch so, damit hast du deine Factory als abstract factory schon korrekt verabreitet.
Ach verdammt, ich hab da ne winzigkeit nicht beachtet :D
Dadurch hab ich keinen Context zur Verfügung über den ich per DIService die Postbox erzeugen kann, insofern muss ich die Factory leider doch behalten.
Mist.

edit:
Es gäbe zwar noch die Möglichkeit context und language als 2. und 3. Parameter an die statische Factory-Funktion zu übergeben, aber ich denk das ist nicht ganz sauber, oder?
Habs jetzt erst mal mit Factory umgebaut, Verwendung sieht so aus jetzt:

Code: Alles auswählen

/* @var $PostboxFactory PostboxFactory */
$PostboxFactory = $this->getServiceObject('extensions::postbox::biz', 'PostboxFactory');

/* @var $Postbox Postbox */
$Postbox = $PostboxFactory->getPostbox($User);
 
Die Factory lädt intern die Postbox per DIServiceObject und setzt den übergebenen User.

Benutzeravatar
Screeze
Beiträge: 1920
Registriert: 05.08.2009, 09:49:04
Kontaktdaten:

Re: Nachrichtensystem

Beitrag von Screeze » 05.06.2011, 12:32:40

Zu deinem Punkt:
Warum hat die Klasse PostboxFolder einen Konstruktor? Das wäre doch bei Vererbung von PostboxFolderBase
nicht notwendig
Hab ich jetzt nochmal nachgesehen: Der Konstruktor wäre zwar nicht notwendig, es funktioniert durch die Vererbung, jedoch lasse ich diesen durch den Generator immer vorsichtshalber mit generieren, damit niemand auf die Idee kommt einen eigenen Konstruktor in sein Objekt einzubauen, ohne den parent-konstruktor aufzurufen. Das sind ~4 Zeilen Code pro Objekt, ich denke die sollten wir drin lassen damit niemand auf die Nase fällt an dieser Stelle.

Die anderen Änderungen sind jetzt im SVN.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4527
Registriert: 04.11.2007, 16:13:53

Re: Nachrichtensystem

Beitrag von dr.e. » 05.06.2011, 23:20:08

Korrekt, das Thema Context hatte ich da auch nicht bedacht. :roll: Der Konstruktor passt für mich ebenso.
Viele Grüße,
Christian

Benutzeravatar
Screeze
Beiträge: 1920
Registriert: 05.08.2009, 09:49:04
Kontaktdaten:

Re: Nachrichtensystem

Beitrag von Screeze » 06.06.2011, 15:52:47

Gut, die Doku im Wiki ist nun auch auf die Änderungen angepasst.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4527
Registriert: 04.11.2007, 16:13:53

Re: Nachrichtensystem

Beitrag von dr.e. » 06.06.2011, 16:44:18

Perfekt! :)
Viele Grüße,
Christian

Coach83
Beiträge: 271
Registriert: 13.05.2010, 17:33:12
Kontaktdaten:

Re: Nachrichtensystem

Beitrag von Coach83 » 04.11.2011, 14:21:28

vielleicht noch ne sinnvolle Erweiterung für alle:
Ne Methode countUnreadMessageChannels() zum direkten Anzeigen der Anzahl an neuen Nachrichten..?!

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast