PHP Sammelthread: Zend Framework und alles was dazugehört

ice-breaker schrieb:
richtig, und gerade so Dinge wie der URL-Helper der Arrays als Input möchte, ist doch in Smarty nicht ordentlich umsetzbar.
Ich war bisher ein großer Verfechter von Smarty, aber mit Zend_View hat es für mich in ZF-Projekten ausgedient.
Zum Vergrößern anklicken....

Ja das hatte ich z.B. als Problem letztens mal. Aber nunja, man muss auch Abstriche machen. Ich möchte meine Templates per WYSIWYG (speziell den CKEditor) bearbeiten können im Adminpanel und da dann ungerne die Möglichkeit geben PHP-Code zu benutzen / benutzen zu "müssen".
 
Sebmaster schrieb:
Andere/Bessere Ansätze, oder ist mein Ansatz so gut?
Zum Vergrößern anklicken....
da der Bootstrap immer komplett initialisiert, ja, das ist der richtige Ansatz.

chrissel schrieb:
Ja das hatte ich z.B. als Problem letztens mal. Aber nunja, man muss auch Abstriche machen. Ich möchte meine Templates per WYSIWYG (speziell den CKEditor) bearbeiten können im Adminpanel und da dann ungerne die Möglichkeit geben PHP-Code zu benutzen / benutzen zu "müssen".
Zum Vergrößern anklicken....
joa, kommt eben auf die Anforderungen an



Btw habe ich da nochwas nettes, was bestimmt einige net kennen:
PHP: 
$application = new Zend_Application(
    APPLICATION_ENV,
    array('config' => array(
    	APPLICATION_PATH . '/configs/application.ini',
    	APPLICATION_PATH . '/configs/config.ini',
    	APPLICATION_PATH . '/configs/routes.ini',
    ))
);
$application->bootstrap()->run();
damit lässt sich die Konfiguration aufteilen ;)
 
ice-breaker schrieb:
Btw habe ich da nochwas nettes, was bestimmt einige net kennen:
PHP: 
$application = new Zend_Application(
    APPLICATION_ENV,
    array('config' => array(
    	APPLICATION_PATH . '/configs/application.ini',
    	APPLICATION_PATH . '/configs/config.ini',
    	APPLICATION_PATH . '/configs/routes.ini',
    ))
);
$application->bootstrap()->run();
damit lässt sich die Konfiguration aufteilen ;)
Zum Vergrößern anklicken....

Puh, ich denke, dass routes.ini alles von config.ini und application.ini überschreiben würde? Und config.ini dementsprechend von application.ini? Oder wie läuft das dort dann ab?
Aktuell lese ich eine Konfiguration aus und füge dann eine weitere zu dem Zend_Config Objekt hinzu. Funktioniert natürlich auch super, aber wenn es da schon direkt so eine Möglichkeit gibt...
 
das wird einfach alles gemerged ;)
Klar, doppeltes wird überschrieben, aber das sollte es ja eh nicht geben.

Habe die Möglichkeit auch erst beim lesen des Zend_Application Sourcecodes zu finden, davor habe ich auch manuell die Zend_Config-Objekte gemerged, aber so ist es eine ganze Ecke sauberer und leichter Configs hinzuzufügen.
 
begrüße!

mal wieder ne frage.. ;)

ich habe einen abstrakten view helper geschrieben.. es geht darum "bearbeitungsbilder" anzuzeigen.. zunächst wird überprüft, ob der benutzer die benötigten rechte hat und ob er sich im bearbeitungsmodus befindet.. wenn dem so ist, dann wird das bild als link angezeigt..

mein gedanke war es jetzt, den abstrakten view helper zu schreiben, in dem die methode ist, die die bilder zusamenbaut (oder eben auch nicht.. je nach dem ;) ) und diese dann für die verschiedenen "bearbeitungstypen" zu erweitern.. also zb EditImg, DelImg.. das hat den vorteil, dass ich dann in den erbenden klassen die pfade zu bilddateien und ähnliches angeben kann und das nicht direkt im view teil machen muss..

das problem ist jetzt aber, dass zb in der Klasse App_View_Helper_EditImg eine methode EditImg() erwartet wird.. die methode mit der logik ist allerdings in der abstrakten klasse, von der geerbt wird und heißt anders.. ich habe es jetzt mit einem wrapper gelöst.. also zb in App_View_Helper_EditImg steht dann:
PHP: 
public function EditImg($resource, $href, $attributes = null)
{
    return $this->EditImgAbstract($resource, $href, $attributes);
}

diese lösung finde ich allerdings nen wenig unschön.. gibt es da ne andere möglichkeit?
 
ist doch korrekt.
Aber das mit der abstrakten Klasse klingt für mich etwas suspekt, was ist denn da alles drinne ?
 
in der abstrakten klasse ist die methode, die dann den html code (also <a ....> <img .... /> </a>) erzeugt oder eben einen leeren string zurückgibt, wenn der benutzer keine rechte hat oder der bearbeitungsmodus deaktiviert ist..

in den klassen, die die abstrakte klasse erweitern, stehen dann nur angaben wie der pfad zur bilddatei und ein standard alt tag.. diese angaben müsste man sonst nämlich bei jedem aufruf des view helpers übergeben..

ich hätte im view also anstelle von:
PHP: 
$this->delImg('someresource', 'delete/some/thing');
sowas:
PHP: 
$this->editImg('someresource', 'delete/some/thing', array(
                                                  'src' => 'del.gif', 
                                                  'alt' => 'Löschen', 
                                                  'title' => 'Löschen'
                          ));

und da die verschiedenen "bildtypen" ja öfters vorkommen dachte ich mir es wäre ne feine sache, das an einer zentralen stelle zu machen und dann eben klassen zu erstellen um die einstellungen für bestimmte bildtypen fix zu machen..

es gibt dann eben eine klasse für die bilder zum bearbeiten, zum löschen, zum nach oben verschieben, nach unten verschieben etc.. und in den klassen selbst sind dann wie gesagt nur pfad, alt und title tag gespeichert, der rest, also die logik ist dann in der abstrakten klasse..
 
Zuletzt bearbeitet:
Neija dein Ansatz ist eigentlich ok, bis auf einen riesen Fehler:
Warum zur Hölle darf dein View Benutzerrechte prüfen?
Der View prüft nichts, nadar, niente

Lass von deinem Controller das Benutzerrecht übergeben und gib ihm deinem Helper als Parameter:
PHP: 
$this->editImg($this->allowedEdit, 'delete/some/thing', array(
  'src' => 'del.gif', 
  'alt' => 'Löschen', 
  'title' => 'Löschen'
));

Der View ist nur zum Rendern da, Businesslogik (Prüfen von Rechten) ist dort fehl am Platz.
 
ice-breaker schrieb:
Der View ist nur zum Rendern da, Businesslogik (Prüfen von Rechten) ist dort fehl am Platz.
Zum Vergrößern anklicken....
Stimmt ich dir voll und ganz zu. Aber meiner Meinung nach gibts da ne Aussnahme, bei der ich nicht unbedingt jedesmal in jedem Controller (wie hier) die Rechte prüfen möchte.
Wenn ich viele Seiten habe, die aber alle nur mit bestimmten Aufrufbar sind, prüfe ich vor der Ausgabe des Links, ob der Zugriff erlaubt ist. Das mache ich mit einem ViewHelper (also nicht direkt im View, aber im Grunde doch :ugly: wie bei WhiZZler)
Oder hast du da nen besseren Vorschlag? Ich möchte ungerne von nen paar dutzend Links die Prüfung in Variablen speichern, die ich dann immer prüfe.
 
Wenn man solch eine Begründung bringt, und das auch gut definiert, kann man Strukturen natürlich aufbrechen.
Sauber ist es natürlich aber nicht mehr (der andere Ansatz aber natürlich auch nicht).

Es sollte aber wenigstens der Controller den ACL-Ressourcenamen an den View-Liefern, wenn du im View nochmal extra eine Dependency zu den ACL-Ressourcenamen machst, ist das höchst fragwürdig. So würde nämlich eine Änderung in den Controllern auch eine Änderung des Views benötigen (nicht sehr dolle oder?).
 
ice-breaker schrieb:
Es sollte aber wenigstens der Controller den ACL-Ressourcenamen an den View-Liefern, wenn du im View nochmal extra eine Dependency zu den ACL-Ressourcenamen machst, ist das höchst fragwürdig. So würde nämlich eine Änderung in den Controllern auch eine Änderung des Views benötigen (nicht sehr dolle oder?).
Zum Vergrößern anklicken....
Jo, aber dann muss man ja auch wieder jede Ressource einzeln übergeben, wenn das alles andere Controller sind :-? Ist halt alles irgendwie unschön :mrgreen:

Ich lös das bei mir aber noch ein wenig anders, ich übergeb den Namen der Route und zieh mir dann daraus den Controller und die Action. Darauf basiert auch mein Ressource Name. Und da ich den Namen der Route eh ziemlich oft im Code verwende (URLs), besteht die Dependency eh.
 
Kurze Frage: Sollte ich es wenn möglich vermeiden Zend_Dom_Query im produktiven Einsatz zu verwenden?
Denn wenn ich mir da die Infos durchlese soll das wohl nicht dafür gedacht sein.

Ich bekomme per POST den Inhalt von einem HTML-Element (div-Tag über ID erreichbar) und möchte diesen Inhalt denn durch den aktuellen Inhalt ersetzen.

Mit Hilfe von PHP5 kann man das ja sicherlich auch lösen, aber wenn ich hier nun schon mit dem ZendFramework arbeite, möchte ich natürlich schon bei diesem Framework bleiben ;)
 
hmm.. an das mit der dependency hatte ich gar nicht gedacht.. da weiß ich eh nich so recht, wie ich das koppeln soll.. namen der einzelnen resourcen sollen in einer datenbank verwaltet werden.. in der datenbank sind die namen der resourcen dann also leicht zu verändern, im code sind die namen aber fest codiert.. das gefällt mir irgendwie gar nicht, aber ich habe keine ahnung, wie ich das besser lösen könnte..

wegen der rechteüberprüfung im view.. gut möglich, dass das aus puristischer sicht ungeeignet ist.. aber ich finde es eben um einiges praktischer und flexibler, als das komplett im controller zu machen.. es geht auch nur darum, ob eine grafik angezeigt wird oder nicht.. ob die aktion dann auch wirklich durchgeführt werden kann und so weiter wird dann nochmal im controller oder aber im model überprüft..
 
chrissel schrieb:
Kurze Frage: Sollte ich es wenn möglich vermeiden Zend_Dom_Query im produktiven Einsatz zu verwenden?
Denn wenn ich mir da die Infos durchlese soll das wohl nicht dafür gedacht sein.
Zum Vergrößern anklicken....
neija ich vermute einfach mal, weil die Erkennung der richtigen Blöcke nicht immer 100% richtig sein wird (malformed HTML) oder weil die Performance möglicherweise nicht so berauschend ist, aber sonst würde ich da kein Problem sehen.

chrissel schrieb:
Ich bekomme per POST den Inhalt von einem HTML-Element (div-Tag über ID erreichbar) und möchte diesen Inhalt denn durch den aktuellen Inhalt ersetzen.
Zum Vergrößern anklicken....
Ich habe 2 Fragen: Warum und Wieso? :biggrin:
Ok, Spaß beiseite, klingt irgendwie nach einem sehr komischen Ansatz, möchtest du den haarklein ausführen, dass jeder Trottel (ice) den Grund versteht? :biggrin:
So lange ich keinen Proxy bauen müsste, der HTML-Seiten verändert würde mir nicht einfallen, warum ich bestimmte Teile eines HTML-Dokuments ändern sollte.

WhiZZler schrieb:
hmm.. an das mit der dependency hatte ich gar nicht gedacht.. da weiß ich eh nich so recht, wie ich das koppeln soll.. namen der einzelnen resourcen sollen in einer datenbank verwaltet werden.. in der datenbank sind die namen der resourcen dann also leicht zu verändern, im code sind die namen aber fest codiert.. das gefällt mir irgendwie gar nicht, aber ich habe keine ahnung, wie ich das besser lösen könnte..
Zum Vergrößern anklicken....
8O
jetzt versteh ich aber gar nichts mehr :biggrin:
Um was für Resourcenamen (ACL?) geht es, und warum sollten diese über die Datenbank veränderbar sein und in der Anwendung fest verdrahtet?
Noch dazu, weil diese Resourcenamen ja scheinbar ein Implementierungsdetail sind und es somit keinen Grund gibt, diese in der Datenbank zu speichern.





irgendwie habe ich schon die ganzen letzten Seiten dieses Threads das Gefühl, dass ich euch nicht verstehe :biggrin:
 
ice-breaker schrieb:
Ich habe 2 Fragen: Warum und Wieso? :biggrin:
Ok, Spaß beiseite, klingt irgendwie nach einem sehr komischen Ansatz, möchtest du den haarklein ausführen, dass jeder Trottel (ice) den Grund versteht? :biggrin:
So lange ich keinen Proxy bauen müsste, der HTML-Seiten verändert würde mir nicht einfallen, warum ich bestimmte Teile eines HTML-Dokuments ändern sollte.
Zum Vergrößern anklicken....

Naja, ich möchte nun mal HTML-Seiten verändern. Man lädt eine Seite, wählt was aus, ändert es und dann wird per AJAX die Änderung zum Server geschickt und durchgeführt.
Nur stehe ich da gerade noch vor ein paar größeren Problemen als dieses. Aber da werde ich selber erst einmal lange drüber grübeln wie man es für den Benutzer am Ende am einfachsten gestalten könnte und diese Probleme dadurch verschwinden.. 8)
 
ice-breaker schrieb:
8O
jetzt versteh ich aber gar nichts mehr :biggrin:
Um was für Resourcenamen (ACL?) geht es, und warum sollten diese über die Datenbank veränderbar sein und in der Anwendung fest verdrahtet?
Noch dazu, weil diese Resourcenamen ja scheinbar ein Implementierungsdetail sind und es somit keinen Grund gibt, diese in der Datenbank zu speichern.
Zum Vergrößern anklicken....

ach.. kacke.. du hast ja recht :D wenn man die resourcennamen direkt in der anwendung stehen, dann erübrigt sich die frage nach der kopplung und es macht auch generell irgendwie mehr sinn..

ich werde dann wohl einfach Zend_Acl erweitern und dort dann klassenkonstanten anlegen und dann ne methode schreiben, welche dann die resourcen mit den beziehungen untereinandern anlegt..
 
ist es irgendwie porblematisch, in einem formular (Zend_Form) über Zend_Controller_Front::getInstance()->getRequest() den request zu holen um dann einen parameter auszulesen? um dann ein model zu erstellen und mit diesem parameter über das model daten zu bestimmen? oder würdet ihr diese daten über den controller an das formular übergeben?

ich sehe da keine probleme mit der ersten variante.. aber wär ja nich das erste mal, dass ich irgendwelche sachen übersehe, die dann doch gar nid so richtig praktikabel sind :D
 
über den Konstruktor ist es deutlich schöner ;) Besonders weil du dann keine versteckte Abhängigkeit zum FrontController und Model hast ;)

also folgendermaßen:
PHP: 
App_Form_Whizzler extends Zend_Form_Abstract {
  protected $_user;

  public function __construct(App_Model_User $user) {
    $this->_user = $user;
    parent::__construct(array());
  }

  public function init() {
    // use $this->_model
  }
}
Die Klasse hält sich zwar nicht mehr daran, dass man im Konstruktor alle Daten für Zend_Form übergeben kann, dafür hat man meiner Meinung nach wirklich sehr schön alles definiert.
Man sieht direkt, dass das Formular Daten eines Models benötigt, und die Deklaration aller Felder findet intern statt.
 
grade abgestimmt.. bin da ganz klar deiner meinung.. dazu, dass man das ganze in CamelCase besser lesen kann, kommt noch, dass man es so gewohnt ist und es aus anderen programmiersprachen so kennt (bei mir JAVA)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben