• Jeder User im Forum verpflichtet sich zur Akzeptanz und zur Einhaltung dieser Regeln:
    1. Umgangston
      Ein angemessener höflicher Umgangston, ohne Beleidigungen, Beschimpfungen und aggressive Postings ist für jedes Mitglied Pflicht.
    2. Beiträge
      Jedes Mitglied sollte sich bemühen nur sinnvolle Beiträge zum Thema zu posten. Dabei ist unbedingt vorher zu prüfen, ob das Thema vorher schon einmal diskutiert wurde und daher fortgesetzt werden kann
      • Suchfunktion benutzen!
      • offizielle Doku lesen!
    3. Haftung
      Jeder Beitragsersteller übernimmt die alleinige Verantwortung seiner Inhalte.
    4. Werbung
      Wir erlauben keine Beiträge, Signaturen, Private Nachrichten oder eMails an Benutzer, die Werbung enthalten. Ausgenommen
      sind Stellengesuche /-angebote, welche ausschließlich im Forum "Stellengesuche" veröffentlicht werden dürfen.
    5. Verstöße
      Regelwidrige Beiträge sollten dem Team gemeldet werden. Nach deren Überprüfung werden wir schnellstmöglich
      entsprechend handeln.
    6. Authorität
      Den Anweisungen der Team-Mitglieder (Administratoren und Moderatoren) sind in diesem Forum Folge zu leisten.
      Bei Fragen oder Beschwerden bitte an diese wenden.
    Wir möchten Euch darauf aufmerksam machen, dass es bei Verstößen gegen einen oder mehreren der oben genannten
    Punkte dem Team frei steht entsprechend zu handeln. Dies kann z.B. das Löschen eines Beitrags, das Ausschliessen bzw.
    Sperren von Mitgliedern oder aber lediglich eine Verwarnung sein.

    In diesem Zusammenhang sollte erwähnt werden, dass das Forum automatisch die IP-Adresse jedes Beitrag-Erstellers
    speichert. Bei schweren Vergehen, behalten wir es uns vor, die IP-Adresse zur Strafverfolgung weiterzugeben.
  • Willkommen im Zend Framework Forum

    ZF1 Zend Framework 1 + ZF2 Zend Framework 2

    Das Zend Framework Forum ist seit 2006 die erste Anlaufstelle für Zend Framework Entwickler in Deutschland. Mit über 70.000 Beiträgen und einer steigenden Nutzerzahl bietet das Forum hilfreiche Themen und ZF-Tutorials für professionelle Entwickler, fortgeschrittene Programmierer sowie Zend Framework Einsteiger.
    Wenn dies Dein erster Besuch in der Zend Framework Community ist, lies bitte zuerst die Hilfe - FAQ durch. Du musst Dich registrieren, bevor Du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um die Registrierung zu starten. Du kannst auch jetzt schon Beiträge lesen. Hier im Forum findest Du die Zend Framework Hilfe, die Du suchst!

    Grüße an alle Zend Framework Entwickler. Das Team vom Zend Framework Forum!

    Drupal Agentur

FlashMessenger - Problemchen

N3X

New member
Moin moin,
ich habe nach langer Inaktivität hier mal wieder eine Frage. Ich bin gerade dabei eine Anwendung von mir von ZF2 auf ZF3 zu schwenken und nehme dahingehend einige Anpassungen vor für die Migration auf das 3er Framework.

Nun ist es so, dass ich über einen zusätzlichen Controller-Helper den FlashMessenger befeuer:

PHP:
public function addMessages($aMessage, $iHop = 0){
    foreach($aMessage as $sType => $sMessage){
        $this->addMessage($sType, $sMessage, $iHop);
    }
    return $this;
}

public function addMessage($sType, $sMessage, $iHop = 0){
    $this->getFlashMessenger()->addMessage($sMessage, $sType, $iHop);
    return $this;
}
Anschließend parse ich die Nachrichten im View mittels des für den FlashMessenger vorgesehenen Plugin:

PHP:
$flash = $this->flashMessenger();
//var_dump($flash->getPluginFlashMessenger()->getMessages());
$flash->setMessageOpenFormat('<div %s role="alert">
         <button type="button" class="close" data-dismiss="alert" aria-label="Close"><span aria-hidden="true">×</span></button>
         ')
    ->setMessageSeparatorString('<br>')
    ->setMessageCloseString('</div>');


echo $flash->render('error',   array('alert', 'alert-dismissible', 'alert-danger'));
echo $flash->render('info',    array('alert', 'alert-dismissible', 'alert-info'));
echo $flash->render('warning', array('alert', 'alert-dismissible', 'alert-warning'));
echo $flash->render('success', array('alert', 'alert-dismissible', 'alert-success'));
Nun stelle ich bei der Umstellung fest, dass bei der Übergabe der Nachrichten mit einem Hop von 1 die Nachrichten ausgegeben werden, nach einem erneuten Seitenreload (soweit so gut). Wird allerdings ein Hop von 0 übergeben (was bislang in der zweiter Version prächtig funktioniert hat), sollen die Nachrichten beim rendern des Views sofort ausgegeben werden, dies scheint jedoch leider nicht mehr zu funktionieren und es endet letztlich darin, dass keine Ausgaben mehr erfolgen.

Kennt jemand das Problemchen bereits oder hat ggf. eine Idee woran es liegen könnte?
 
Zuletzt bearbeitet:

Kaiuwe

Super-Moderator
Wird allerdings ein Hop von 0 übergeben (was bislang in der zweiter Version prächtig funktioniert hat), sollen die Nachrichten beim rendern des Views sofort ausgegeben werden, dies scheint jedoch leider nicht mehr zu funktionieren und es endet letztlich darin, dass keine Ausgaben mehr erfolgen.
Ich kann leider dein Ziel nicht erkennen bzw. was möchtest du erreichen? Warum muss es 0 sein?


Nebensache:
Nun ist es so, dass ich über einen zusätzlichen Controller-Helper den FlashMessenger befeuer:
Ein Controller-Plugin ist doch bereits vorhanden?!

PHP:
$flash->setMessageOpenFormat('<div %s role="alert">
         <button type="button" class="close" data-dismiss="alert" aria-label="Close"><span aria-hidden="true">×</span></button>
         ')
    ->setMessageSeparatorString('<br>')
    ->setMessageCloseString('</div>');
Kannst du in die Konfiguration verschieben. Beispiel:
PHP:
'view_helper_config' => [
    // Flash messenger
    'flashmessenger' => [
        'message_open_format'      => '<div%s>',
        'message_close_string'     => '</div>',
        'message_separator_string' => '<br>',
    ],
],
 

N3X

New member
Ich kann leider dein Ziel nicht erkennen bzw. was möchtest du erreichen? Warum muss es 0 sein?
Ich möchte die Meldungen sofort echon, wenn die Controller-Methode abgearbeitet ist und das View gerendert wird. Nicht erst wenn der Controller abgearbeitet ist, beim nächsten manuellen Reload.


Ein Controller-Plugin ist doch bereits vorhanden?!
Jup weiß ich, aber ich bin ein Freund von vereinfachen. Das Standard-Controller Plugin bietet keine Möglichkeit um eine Masse an gemischen Nachrichten (namespaces) zu übergeben (luxusproblemchen).


Kannst du in die Konfiguration verschieben
Weiß ich, aber da ich eh noch am rumprobieren bin, habe ich das erst einmal gelassen.
 

Kaiuwe

Super-Moderator
Ich möchte die Meldungen sofort echon, wenn die Controller-Methode abgearbeitet ist und das View gerendert wird. Nicht erst wenn der Controller abgearbeitet ist, beim nächsten manuellen Reload.
Das geht doch einfacher: Zend\View\Helper\FlashMessenger::renderCurrent()


Jup weiß ich, aber ich bin ein Freund von vereinfachen. Das Standard-Controller Plugin bietet keine Möglichkeit um eine Maße an gemischen Nachrichten (namespaces) zu übergeben (luxusproblemchen).
Ob das eine Vereinfachung ist, würde ich als fraglich bezeichnen. Du hast neuen Code erzeugt, welcher ebenfalls getestet und gewartet werden muss. ;)
 

N3X

New member
RenderCurrent habe ich auch schon probiert. Irgendwas klemmt.

Zum Thema Wartung und Pflege:
Es ist mir lieber Sourcecode an einer Stelle pflegen zu müssen, als wenn ich beim hinzufügen der Nachrichten zum Namespace ggf. komplette Klassen abklappern muss (sofern sich Änderungen ergeben) um z.B. Methodennamen anpassen zu müssen o.a.
 
Zuletzt bearbeitet:

Kaiuwe

Super-Moderator
RenderCurrent habe ich auch schon probiert. Irgendwas klemmt.
Dann prüf dies mal.

Einfaches Beispiel:
PHP:
// Error messages
echo $this->flashMessenger()->renderCurrent(
    Zend\Mvc\Controller\Plugin\FlashMessenger::NAMESPACE_ERROR,
    [
        'alert-box',
        'alert',
    ]
);
…als wenn ich beim hinzufügen der Nachrichten zum Namespace ggf. komplette Klassen abklappern muss (sofern sich Änderungen ergeben) um z.B. Methodennamen anpassen zu müssen o.a.
Kann dir leider nicht ganz folgen. Warum willst du etwas ändern?

Davon mal abgesehen, verstehe ich auch deinen Anwendungsfall nicht:
Das Standard-Controller Plugin bietet keine Möglichkeit um eine Masse an gemischen Nachrichten (namespaces) zu übergeben
Wenn etwas erfolgreich war, dann fügt man eine Meldung mit entsprechenden Namespace hinzu. Bei einem Fehler ebenfalls nur eine Meldung und den passenden Namespace.
 

N3X

New member
Hab das Problemchen mittlerweile gefunden. Hab eine Anpassung vergessen zu machen (so einfach kann's sein).

Stattdessen hab ich allerdings ein anderes Problemchen, alle paar Requests wird mir in einer Action ein transparentes icon gerendert statt dem View.


Kann dir leider nicht ganz folgen. Warum willst du etwas ändern?
Ich will nichts ändern, nur bei zukünftigen Änderungen im Framework, oder Fremdbibliotheken muss ich weniger anpassen. Größtes Bsp bei der Migration von ZF2 zu ZF3 ist z.B. der Entfall von EventManager::attach(),
statt alle Klassen abzuklappern um ggf. Methoden zu ändern brauche ich nur eine Klasse anzufassen. Warum sich das Leben schwer machen und ein komplettes Projekt nach explementierten Methoden absuchen, wenn man sich das Leben einfach machen kann ?


Davon mal abgesehen, verstehe ich auch deinen Anwendungsfall nicht
Ich habe gemischte Ergebnisse in meinen Anwendungsfällen, es kann vorkommen, dass mein Array mit den Nachrichten sowohl errors als auch success benachrichtigungen enthalten kann o.a.
Warum sollte ich jedes mal bei der Verarbeitung von Nachrichten Schleifen redundant implementieren?

Würde bedeuten, jedes mal wenn ich meine Nachrichten verarbeite um sie an den FlashMessenger zu bringen müsste ich mich im Sourcecode wie folgt wiederholen:

PHP:
$aMessages = $this->getExampleService()->getMessages();
foreach($aMessages as $sType => $sMessage){	$this->FlashMessenger()->addMessage($sMessage, $sType, 1);}
Dann hätte ich mehrfachen funktionalen Sourcecode redundant in allen Controllern, der Wartungs- & Pflegeaufwand dabei ist doch gerade enormer als eine winzige Funktionalität in einer zentralen Methode/Klasse unterzubringen.
Nehmen wir an die Methode addMessage würde sich von den Übergabeparametern ändern, wirst du dann durch ein komplettes Projekt gehen um überall dort die Übergabeparameter anzupassen? Bei kleinen Projekten ist der Anpassungsaufwand dann evtl. minimal. Aber wie sieht es bei größeren Projekten aus? Die Einzige Variation die evtl. noch zum Sourcecode iwo auffindbar wäre, wäre das der Übergabeparameter "hop" ggf. von Controller zu Controller sich unterscheidet.

Aber ansonsten führt es halt zu nicht zwingend notwendiger Sourcecode Redundanz. Vor allem was willst du machen, wenn du z.B. irgendwann auf die Idee kommst Fehlermeldungen mit einem Statuscode zu präfixen oder sonstiges? Durch x Klassen durchgehen und an jeder Stelle eine Anpassung vornehmen?

Ich hoffe das ist vom Gedanken ausführlich genug.
 
Zuletzt bearbeitet:

Kaiuwe

Super-Moderator
Stattdessen hab ich allerdings ein anderes Problemchen, alle paar Requests wird mir in einer Action ein transparentes icon gerendert statt dem View.
:confused: Was für ein „transparentes Icon“? Vom Browser, von der Anwendung oder woher?

Ich will nichts ändern, nur bei zukünftigen Änderungen im Framework, oder Fremdbibliotheken muss ich weniger anpassen. Größtes Bsp bei der Migration von ZF2 zu ZF3 ist z.B. der Entfall von EventManager::attach(),
statt alle Klassen abzuklappern um ggf. Methoden zu ändern brauche ich nur eine Klasse anzufassen. Warum sich das Leben schwer machen und ein komplettes Projekt nach explementierten Methoden absuchen, wenn man sich das Leben einfach machen kann ?
Wenn ich dich richtig verstehe, dann machst du dir das Leben schwer, weil du überall einen Wrapper drumherum setzt. Der „FlashMessenger“ als Beispiel taucht doch nur im Kontroller als Plugin auf und im View-Skript als Helfer (ebenfalls Plugin). Ein Ersetzen geht relativ einfach, da main jeweils nur neue Plugins registrieren muss.
Tauscht man die Kontroller aus oder verwirft man diese, weil zukünftig auf „Zend Expressive“ gesetzt werden soll, dann ist dies ebenfalls kein Problem, denn von Anfang an sollte auf das Konzept der „Thin Controller“ aufgebaut werden.

Jetzt kommt das große „Aber“: Plugins austauschen, Kontroller verwerfen, Datenbank-Abstraktionsebene wechseln und ähnliches sind nicht die täglichen Programmierprobleme. Du läufst hier in das Problem, welches mit „Don't Overdesign“ beschrieben werden kann. Konzentriere dich auf aktuelle Problem und nicht auf das was vielleicht in der Zukunft kommen könnte. Ebenfalls kommt hier „YAGNI - You aren't gonna need it“ zum Tragen.

Das Framework soll deinem eigenen Code nicht im Wege stehen –*soweit stimme ich dir vollkommen zu. Dies heißt aber nicht, dass du alles ummanteln und hinter Fassaden verstecken oder per Proxy aufrufen sollst.

Ich schlage einfach mal eine andere Variante vor: Warum bringst du deine Ideen, Verbesserungen oder Probleme nicht in das Open-Source-Projekt ein? Immerhin arbeiten und reden wir hier über ein „offenes“ System, was genau davon lebt. Dies könnte nicht nur deinen Code verbessern, sondern auch der vom ZF und alle anderen Anwendungen die ebenfalls darauf aufbauen.

Ich habe gemischte Ergebnisse in meinen Anwendungsfällen, es kann vorkommen, dass mein Array mit den Nachrichten sowohl errors als auch success benachrichtigungen enthalten kann o.a.

PHP:
$aMessages = $this->getExampleService()->getMessages();
Was sind das für Meldungen? Kannst du mal konkret werden? (Wieso sind hier gleichzeitig Erfolgs- und Fehlermeldungen enthalten?!)
 

N3X

New member
PHP:
Was für ein „transparentes Icon“? Vom Browser, von der Anwendung oder woher?
That is a good Question... Kann ich dir leider nicht konrekt beantworten, ich vermute nicht, dass ich das Icon vom Webbrowser erhalte, da ich dieses Szenario bereits sicherheitshalber in drei unabhängigen Browsern getestet habe.
Bei weiterer Recherche habe ich herausgefunden, dass das Icon als transparentes Icon (Suche nach Base64-string) verwendet wird.

HTTP/1.1 200 OKContent-Type: image/gifCache-Control: max-age=300Content-Length: 43

Base64-Response: R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==
Wenn ich dich richtig verstehe, dann machst du dir das Leben schwer, weil du überall einen Wrapper drumherum setzt.
Was nicht ganz richtig ist... Überall ist definitiv übertrieben, aber siehe z.B. bei zend-view. FlashMessenger als Helper für View ist mittlerweile deprecated und soll in der V3 irgendwann mal explementiert werden. Die Änderungen die bei der tatsächlichen Explementierung erfolgen, sind noch recht offen, meiner Ansicht nach.

Konzentriere dich auf aktuelle Problem und nicht auf das was vielleicht in der Zukunft kommen könnte
Auch das ist ein berechtiger Punkt, aber ich habe es oftmals schon während der Produktentwicklung erlebt, dass genau solche Kleinigkeiten in größeren CRs ausarten können, die dann nicht mal "ebenso" zu lösen sind. Zudem sprach niemand davon, dass jeder Methodenaufruf hinter ummantelt, hinter Fassaden oder Proxies steckt.

Es gibt sicher genug Leitsätze die Pro oder Contra sind für ein und das selbe Thema. Ich weiß genau worauf du mit YAGNI hinauszielen willst (so als PO habe ich da auch meine Erfahrungen).

Ich schlage einfach mal eine andere Variante vor: Warum bringst du deine Ideen, Verbesserungen oder Probleme nicht in das Open-Source-Projekt ein? Immerhin arbeiten und reden wir hier über ein „offenes“ System, was genau davon lebt. Dies könnte nicht nur deinen Code verbessern, sondern auch der vom ZF und alle anderen Anwendungen die ebenfalls darauf aufbauen.
Jau, da schlägst du ein gutes Kapitel auf. Sicher würde ich mich gerne auch im Open-Source-Projekt einbringen, wenn ich die Zeit dafür hätte.
Meistens, kennst du sicher selbst, will man sich nach der Arbeit mit so einer Thematik nicht rumschlagen. Dadurch sind bei mir bereits so einige private Projekte zu kurz gekommen. Beruflich bin ich auch eher weniger im Bezug auf ZF (abgesehen vom 1er Framework / 2er im Kontext PIM-Systeme / allg. SAP) unterwegs.
 

Kaiuwe

Super-Moderator
Überall ist definitiv übertrieben, aber siehe z.B. bei zend-view. FlashMessenger als Helper für View ist mittlerweile deprecated und soll in der V3 irgendwann mal explementiert werden. Die Änderungen die bei der tatsächlichen Explementierung erfolgen, sind noch recht offen, meiner Ansicht nach.
Die Änderungen sind eindeutig:

@deprecated This helper will be removed in version 3.0 of this component.
At that time, it will be available in zendframework/zend-mvc-plugin-flashmessenger.
https://github.com/zendframework/zend-view/blob/master/src/Helper/FlashMessenger.php#L19

Also keine Sorge! :D
 

N3X

New member
Naja mit verschiedenen Browsern habe ich schon getestet. Leider egal in welchem der gleiche Misserfolg. Dem eigentlichen Problem bin ich nun über die Feiertage nicht nachgegangen, eher war ich unterwegs in Schwerin.
 
Oben