Creator

Hallo@all

Das was ich vor habe, ist etwas schwer zu beschreiben, aber ich versuches es einfach mal!

Ich habe mir vor einer "ewigkeit" mal ein eigens MVC Framework Programmiert, welches seine Dienste sehr gut erfüllt.

Dieses möchte ich jetzt mit einer Art Hilfestellung für den Programmierer erweitern .
Jeder von euch wird es wohl kennen, dass man bei mehreren 100 Files durchaus mal den überblick verlieren kann.
Grade wenn man ein Projekt erweitern möchte/muss, woran man eine längere Zeit nicht mehr gearbeitet hat. Man muss sich einfach wieder einlesen. Auch wenn man vieles gut Dokumentiert hat.
Oder jemand anderes hat diese Projekt Programmiert, welches man jetzt erweitern soll.
Wärend der entwicklung, könnte es sicher auch beim Debuggen helfen.

Gewisse Informationen können diese Zeit der einarbeitung erheblich verkürzen.

Beispiel welche Informationen ich Interessant finde.

1. Welche Controller wurde bei einem Request ausgeführt
2. Welches Layout wird bei diesem Request verwendet.
3. Welche Template Datein werden angezeigt.
4. Was steht in den Superglobalen Arrays. ( $_POST, $_GET, $_SESSION, usw. )
5. Welche Plugins wurden verwendet. ( ACL, Multilanguage, PageBrowser, usw. )

Ich finde, dass dies alles Informationen sind, die dafür Beitragen das ich sehr schnell einen überblick bekomme.

Möchte der "Designer" nur was an einer ausgabe ändern weil er vieleicht ein Tipfehler gefunden hat als Beispiel, brauch er sich nur dort hinklicken und kann sehr schnell erkennen in welchem Template dieser Text steht.
Ohne diese Information, müsste er sich erst durch die ganzen Templatefiles wühlen.
Das gleiche gilt für den Programmierer, sehr schnell findet man den Controller den man haben möchte.

So jetzt zur umsetzung des ganzen.
Diese ganzen Informationen müssen ja erstmal alle gesammelt werden.
Dafür habe ich mir jetzt 3 Regeln ausgedacht.

1. Nur die Infos Sammeln während der Entwicklung, bzw. wenn ich dieses möchte.
2. Framework und die ProgInfo ich nenne das jetzt mal so, sind unabhängig von ein ander. Also keine feste implentierung der ProgInfo.
3. Es sollte keinerleih Performance einbussen durch die nicht nutzung vorhanden sein. Dies würde ja den Produktiveinsatz ja beeinflussen.

Zum 1 Punkt, dies löse ich wie folgt.
Zu Punkt 2 da Grübel ich grade drüber.

Was haltet Ihr hier wenn man das Subject / Observer Pattern verwenden würde? Macht das Sinn oder kennt Ihr noch eine besseren Lösungsweg?

2 Frage, was haltet Ihr im Allgemeinen von dieser Idee?

Mister Ad

robo47

hmm ich weis grad nicht was genau du meinst, aber meinst du z.b. sowas wie das was es hier für das zend framework gibt:

Introducing the Scienta ZF Debug Bar - Joakim Nygård
oder auch
Zeltlblotzbuam.de V3.1

Sowas liese sich ja wenn man es dementsprechend ausbaut und für das jeweilige framework anpasst auch durchaus so erweitert, dass es alle templates listen kann die gebraucht wurden, alle controller und actions sammelt etc ...

Imho sollte man sich, immer überlegen ob man wie in deinem Vorschlag zu einem Observer(able) debug-code ins system fest einbauen will, die komplexität aller klassen die du überwachen können willst würde steigen, dann doch lieber eine art plugin das sich die gewünschten informationen selbst zusammensucht.

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

Creator

Ja sowas meinte ich, wusste garnicht, dass es sowas schon gibt.

Der Zweite Link passt irgendwie nicht zum Theman oder hab ich mich da jetzt vertan?

Ok aber wie komme ich dann an diese Informationen ran? Dafür bräuchte ich im Plugin ( ProgInfo ) ja alle Instanzen von gewissen Objekten.

Bei Manchen wäre das kein Problem, weil die Singelton verwenden. Bei anderen würde es auch gehen, weil diese in der Registry liegen. Aber beim Frontcontroller wüsste ich jetzt nicht wie, außer ich übergebe alle Objekte im Constructor mit.

Würde ja nur Stattfinden, wenn man Programmiert.

Gibt es noch eine andere Variante.

dispy

Warum nimmst du dir nicht einfach den Backtrace und analysierst den ? Erstens lässt er sich leicht ausstellen und belastet das System nicht weiter und zweitens kannst du den dann auf alle anderen Projekte, die genau das gleiche Framework einsetzen, anwenden. Das erste Schreiben von der Parserklasse dürfte halt aufwendiger ausfallen





MfG
dispy

robo47

Bei 2ten Link ist so ein Teil im Einsatz, zeigt Fehler an etc (Javascript vorrausgesetzt)

In irgendeiner Form müssen ja in jeder Architektur Objekte andere Objekte kennen, ich kenne dein Framework nicht, aber im ZF bekommt man sehr viel über den Frontcontroller bekommen, unter anderem das Response-Objekt, das Request-Objekt, den Router und so, andere Instanzen werden oftmals in der Registry des Frameworks abgelegt, die Datenbank-Klasse, die unterstützt beispielsweise Profiler die die Daten über alle Querys mitloggen können, die man sich dann da rausholen kann und so

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

Creator

Du hast absolut recht, manch mal ist der einfachste weg auch der Sinnvollste!
Ich denke immer gerne etwas zu Kompliziert.

fat32

Also in meinem Framework liegen Informationen wie verwendeter Controller, Action, usw. im Request-Objekt

phpdummi

Auch wenn ein Controller einen anderen Aufruft?

__________________
"Nobody is as smart as everybody" - Kevin Kelly
— The best things in life aren't things

fat32

Nein, das steht da nicht drin... Ok, hab wohl das Problem falsch verstanden

Creator

Bei mir auch.

Das gibt es in meinem Framework nicht, da ich das immer recht unübersichtlich finde.
Habt mal 50 Controller, die sich gegenseitig nach einer gewissen logik aufrufen.

Ich habe hier den einfachsten weg gewählt.
Meine Request Klasse, entscheidet an Hand einer ConfigLogik, was wann geladen wird.
Wenn der Page Parameter Controller1 übergeben wird, dann holt sich die Request Klasse aus einem Array die Informationen welche Controller noch bei diesem Request verarbeitet werden müssen.

Bis jetzt bin ich auf keine Probleme gestoßen. Controller können immer noch weitere Controllor einbinden wenn diese wirklich nicht anders gehen sollte.