Thema: var_dump ähnliche Funktion einbauen

Hallo zusammen,

ich habe eine var_dump ähnliche Funktion, die ich von einem Projekt ins nächste mitschleppe. Nun möchte ich sie in ein ZF Projekt einbauen, so daß sie überall verfügbar ist und auch andere Entwickler damit einverstanden sind. Wie mache ich das?

Vielen Dank,
Anja

Laden, Nutzen?
Woran scheiterts?
Ums gleich vorweg zu nehmen: Es gibt keinen PHP-eigenen Autoload-Mechanismus für Funktionen.

Ich hatte sie erst mal als view helper eingebaut, aber so kann ich sie nicht überall verwenden.
Dann hab ich die Funktion mal in der Bootstrap über "class Bootstrap extends Zend_Application_Bootstrap_Bootstrap" eingefügt. Das geht, kann aber so definitiv nicht bleiben.
Vielleicht ein require_once in der index? Aber wo lege ich die Datei am besten ab?

Vielleicht ein require_once in der index? Aber wo lege ich die Datei am besten ab?

Joa, index ginge. Funktionen sind im ZF nicht vorgesehen, deshalb gibts dafür keine Funktion. Habs bei mir kurzfristig einmal unter lib/MyLibrary/functions/* abgelegt. Durch die Kleinschreibung ist eine Verwechslung mit Klassen ausgeschlossen. Kannst dir aber auch jeden anderen ausdenken, zB lib/functions/* oder so.

Zitat von anja

Ich hatte sie erst mal als view helper eingebaut, aber so kann ich sie nicht überall verwenden.
Dann hab ich die Funktion mal in der Bootstrap über "class Bootstrap extends Zend_Application_Bootstrap_Bootstrap" eingefügt. Das geht, kann aber so definitiv nicht bleiben.
Vielleicht ein require_once in der index? Aber wo lege ich die Datei am besten ab?

Normalerweise ist die var_dump() Funktion nur während der Entwicklung nötig. Dafür also einen View Helper o. ä. zu erstellen macht für mich keinen Sinn.

Ich würde die Funktion über den PHP include_path einbinden. So ist sie quasi in jedem Projekt vorhanden.

Wenn du es über die index.php machst ist es nur ein geringer Unterschied dazu sie in der Bootstrap.php einzufügen. Die index.php wäre aber passender. Dort dann zusätzlich auf APPLICATION_ENV prüfen und nur unter development einfügen.

Ok danke, hab einen Ordner angelegt library\Anja\functions\ meine Datei rein und lade sie in der index.

Normalerweise ist die var_dump() Funktion nur während der Entwicklung nötig. ... Die index.php wäre aber passender. Dort dann zusätzlich auf APPLICATION_ENV prüfen und nur unter development einfügen.

Stimmt zwar, aber da man so eine Ausgabefunktion leider auch mal vergisst und damit das live system platt macht, wenn die Funktion fehlt, habe ich diese Prüfung nach APPLICATION_ENV in der Funktion selbst und gebe dann nichts aus.


Andere Frage, wenn gettext eingesetzt wird, kann man _('Name') benutzen oder muss man $this->translate('Name') verwenden?

Und was spricht gegen ein

PHP-Code:

 Zend_Debug::dump($fooBar) 


Wenn man dann auch noch die xDebug - Extension geladen hat sieht das wunderbar aus.

@maetrus: für mich als Anfänger erst mal, dass ich es nicht kenne
Ein Einfügen in einer Action Controller Methode bringt erst mal nur eine weiße Seite Was mache ich falsch?

Ansonsten: Ich habe mir meine Funktion angepasst, so dass sie z.B. Methoden von Objekten anzeigt usw. Kann man Zend_Debug anpassen?

Eine weiße Seite bedeutet meistens, dass die php.ini Einstellung error_reporting die Ausgabe einer Fehlermeldung nicht erlaubt.

Also ich hab es meistens nur so verwendet wie es oben steht. ;-)

Das erspart das lästige

PHP-Code:

echo "<pre>";
var_dump($fooBar);
echo "</pre>"; 


und laut manual scheinbar auch wirklich nur mit der Funktion vorgesehen.

Es spricht nichts dagegen deine eigene Klasse zu schreiben

PHP-Code:

class My_Debug extends Zend_Debug {
    ....
} 


Habe mir die Implementierung noch nicht angesehen, da mir bisher immer die obige Anweisung ausgereicht hat. Ging ja immer nur mal drum um eben in eine Variable rein zu schauen was da drin steckt ...

Zend_Debug::dump($this); hab ich jetzt auch nochmal in einer anderen Action Controller Methode versucht, rödelt lang, dann nix. Meine Funktion tut übrigens an gleicher Stelle.

php.ini:
error_reporting = E_ALL & ~E_NOTICE

application.ini:
[development : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1

Für Entwicklungsumgebungen ist

Code:

E_ALL

oder sogar

Code:

E_ALL | E_STRICT

besser geeignet
display_startup_errors hat (logischerweise) ausserhalb der "php.ini" keinen Effekt.
Es muss phpsettings heißen.

Ich entwickle seit Jahren ohne E_NOTICE, wie auch alle mit denen ich zusammen gearbeitet habe. E_ALL & ~E_NOTICE ist die nicht von mir geänderte default Einstellung der php.ini.

Das verstehe ich nicht:

display_startup_errors hat (logischerweise) ausserhalb der "php.ini" keinen Effekt

Ich entwickle seit Jahren ohne E_NOTICE, wie auch alle mit denen ich zusammen gearbeitet habe. E_ALL & ~E_NOTICE ist die nicht von mir geänderte default Einstellung der php.ini.

Is auch nicht notwendig, aber an vielen Stellen hilfreich. E_STRICT in dem Sinne _noch_ hilfreicher

Das verstehe ich nicht:

Neija, es heißt "display_startup_errors" "Startup" ist in einem PHP-Skript längst vorbei.

Zend_Debug scheitert am $this, was anderes geht. Timeout? Aber warum kommt dann keine entsprechende Fehlermeldung?

Wie gesagt, meine Funktion tut an der Stelle und da sie nur ausgibt was ich brauche sehr schnell. var_dump tut auch, braucht aber so lange, dass es nervt.

Neija, es heißt "display_startup_errors" "Startup" ist in einem PHP-Skript längst vorbei.

Ach so, ich wollt ja auch nur zeigen, dass alle Fehler angeschaltet sind. Auch mit der angeregten Einstellung bekomme ich nur eine weiße Seite, leider

Das hast du berücksichtigt?

Zitat von KingCrunch

Es muss "phpsettings" heißen.

Ja, hab ich, hatte auch gehofft, dass das helfen würde.