registry in taglib

Das Forum soll der Ablage von Lösungen für immer wieder auftauchende Problemstellungen dienen. // This forum contains solutions to problems that frequently occur.
Antworten
hansjo
Beiträge: 38
Registriert: 02.03.2009, 16:22:16
Wohnort: München

registry in taglib

Beitrag von hansjo » 03.05.2010, 00:07:30

Hi mal wieder,

ich bastel hier vor mich hin und habe nun folgendes Problem. Ich schreibe in einem Documentcontroller einen Wert (Objektreferenz) in die Regisry. In einem weiteren Documentcontroller hole ich mir mit

Code: Alles auswählen

 &Singleton::getInstance('Registry');
wieder eine Instanz und lese meinen Wert erfolgreich aus und kann auf dem Objekt arbeiten. Dann binde ich ein template mit eigenem Taglib ein und in der taglib-implementierung will ich wieder im Konstruktor die Registry auslesen. Aber in dem Registy-Objekt dass ich hier bekomme ist mein Wert verschwunden?

Hat das einen logischen Grund und kann so nicht gehen :( oder sollte das eigentlich möglich sein und ich mache irgend was falsch?

Danke!!
Hansjörg

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

Re: registry in taglib

Beitrag von dr.e. » 03.05.2010, 14:45:14

Hallo Hansjörg,

grundsätzlich ist die Registry - im Gegensatz zum Context und der Sprache eines DOM-Knotens - auch immer in vollem Umfang im Konstruktor eines Controllers oder einer Taglib nutzbar. Einziger Knackpunkt ist der Zeitpunkt der Nutzung. Wird dein Controller (in deinem Fall vermutlich das Schreiben des Wertes) vor dem Auslesen ausgeführt, passt alles. Im umgekehrten Fall jedoch nicht, weil der Wert zu spät in die Registry abgelegt wird.

Ich vermute deshalb sehr stark, dass dieser Umstand hier zuschlägt. Denn: eine Taglib, die in einem DOM-Knoten definiert wird, wird immer vor einem Controller auf dem selben Knoten ausgeführt. Das zeigt dir das Timing-Model des Page-Controller. Insofern musst du also dafür sorgen, dass die Information schon vorher in die Registry geschrieben wird, oder du injizierst die Informationen im Controller in die Taglib. Dieser Mechanismus wird beispielsweise auch bei Platzhaltern (z.B. <html:placeholder />) genutzt um die Werte in die Taglib-Instanz der Klasse html_taglib_placeholder zu schreiben. Einen ähnlichen Mechanismus kann ich mir auch hierfür vorstellen. Das setzt natürlich voraus, dass das auf deinen Anwendungsfall passt.

Ich hoffe, das hilft dir weiter.
Viele Grüße,
Christian

hansjo
Beiträge: 38
Registriert: 02.03.2009, 16:22:16
Wohnort: München

Re: registry in taglib

Beitrag von hansjo » 03.05.2010, 23:08:22

Das mit dem Timing-Model erklärt einiges (hatte ich mir sicher schonmal angesehen aber nicht genau gemerkt).

Dann möchte ich die Gelegenheit nutzen zu fragen ob mein Design grundsätzlich sinnvoll ist (hoffe ich komme mit den Begriffen jetzt nicht durcheinander):

Es wird eine einfache Webseite mit ein paar dynamischen Inhalten (Aktuelle Artikel, Kontaktformular):

Initial lade ich ein template das die Anordnung der einzelnen Bereiche (Header, Nav, Content) definiert und dafür jeweils mit 'core:importdesign' entsprechende weitere templates einbindet. Ferner wird in einem documentcontroller ein Objekt erzeugt, dass alle Navigationsknoten als Baum aus einer Liste der Datenschicht erzeugt. Die referenz dieses Nav-Objekst schreibe ich in die Registry. Im Controller meines Nav-Templates welches als nächstes eingebunden ist generiere ich dann aus dem Nav-Objekt die Navigation. Nun kommt der Content. Den wollte ich dann eben per Taglib einfügen und benötige hierfür ebenfalls das Nav-Objekt (da hierin die Informationen zum Content je Navknoten enthalten sind). ==> Ist das (abgesehen vom timing) so mit dem APF sinnvoll? (soweit man das anhand meiner Darstellung sagen kann).

Ich denke nun ich werde das Nav-Objekt einfach auch in einer Taglib statt im controller erzeugen - dann sollte es gehen?

Hansjörg

hansjo
Beiträge: 38
Registriert: 02.03.2009, 16:22:16
Wohnort: München

Re: registry in taglib

Beitrag von hansjo » 03.05.2010, 23:46:05

So - nun habe ich das Erzeugen meines Nav-Objektes in eine Taglib umgeschrieben und diese beim inital geladenen Template gleich am Anfang mit:

Code: Alles auswählen

<core:addtaglib namespace="tools::myNavtree::taglib" prefix="my" class="navtree" />
<my:navtree />
eingebunden (statt dem Document Controller). aber es geht immer noch nicht :(

==> wenn weiter unten das Template mit dem Content eingebunden wird ist das Nav-Objekt aber immer noch nicht in der Registry bekannt (im Controller für die Navigation dann später aber schon ... die Taglib 'arbeitet' also - nur wann?)

Wäre nochmal für einen Hinweis dankbar!

Hansjörg

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

Re: registry in taglib

Beitrag von dr.e. » 04.05.2010, 12:40:17

Hallo Hansjörg,
Initial lade ich ein template das die Anordnung der einzelnen Bereiche (Header, Nav, Content) definiert und dafür jeweils mit 'core:importdesign' entsprechende weitere templates einbindet.

Das passt so und ist auch mit dem APF eine völlig korrektes Vorgehen.
Ferner wird in einem documentcontroller ein Objekt erzeugt, dass alle Navigationsknoten als Baum aus einer Liste der Datenschicht erzeugt. Die referenz dieses Nav-Objekst schreibe ich in die Registry. Im Controller meines Nav-Templates welches als nächstes eingebunden ist generiere ich dann aus dem Nav-Objekt die Navigation.

Die Frage ist an dieser Stelle: warum generierst du die Navigation nicht direkt im Document-Controller, der die Navi auch ausgibt? Du kannst doch in deinem Haupt-Template per <core:importdesign /> ein Template einbinden, das die Navigation darstellt. Dieses wird durch einen Document-Controller transformiert, der sich die Navi zusammensucht und direkt ausgibt. Du kannst pro Seite beliebig viele Document-Controller haben. Im extremen Fall kann deine Seite aus 20 Einzel-Templates mit 20 Document-Controllern bestehen (siehe HMVC-Prinzip).

Ich denke in deinem Fall ist das Problem aber immer noch das Timing, denn der Document-Controller des Haupt-Templates wird nach der Transformation der Kinder ausgeführt. Wenn du das selbst ausprobieren möchtest, kannst du ja auf deiner lokalen Entwicklungs-Umgebung in die entsprechenden Klassen Breakpoints setzen. Ich würde daher dazu tendieren, die Informationen direkt im Controller, der die Inhalte auch ausgibt zu generieren.
Nun kommt der Content. Den wollte ich dann eben per Taglib einfügen und benötige hierfür ebenfalls das Nav-Objekt (da hierin die Informationen zum Content je Navknoten enthalten sind). ==> Ist das (abgesehen vom timing) so mit dem APF sinnvoll? (soweit man das anhand meiner Darstellung sagen kann).
Es funktioniert beides und es ist auch beides sinnvoll. Die Daumen-Regel hierzu ist immer: "Sobald man mit einer Kombination aus Template und Controller nicht weiterkommt, baut man sich eine Taglib!" In deinem Fall sollte ersteres meiner Ansicht nach reichen, weil du quasi nur eine Baumstruktur an Hand von Fragmenten visualiseren möchtest.
eingebunden (statt dem Document Controller). aber es geht immer noch nicht :(

==> wenn weiter unten das Template mit dem Content eingebunden wird ist das Nav-Objekt aber immer noch nicht in der Registry bekannt (im Controller für die Navigation dann später aber schon ... die Taglib 'arbeitet' also - nur wann?)
Ich vermute - wie oben angesprochen - weiter ein Timing Problem. Kannst du mal den Versuch starten in der index.php einen beliebigen Wert in die Registry zu schreiben und im Tag bzw. dem Controller abzufrage? Das sollte definitiv klappen, ansonsten hat das APF einen Bug. Falls das funktioniert, bestätigt es die Annahme, dass es sich weiter um ein Timing-Problem handelt. In diesem Fall würde ich dann die Logik für das Generieren der Navi in den ausgebenden Controller verlagern.

Design-technisch könnte man auch auf den Front-Controller zurückgreifen und in einer eigenen Action schon vor dem Erzeugen der Seite (new Page()) die Navi aufzubauen. Das ist die übliche Vorgehensweise, wenn man Informationen an mehreren Stellen einer Seite benötigt. Das würde es aber in deinem Fall komplexer gestalten als du es vermutlich benötigst. Sofern du komplexere Seiten hast, ist das aber state-of-the-art. Als Beispiel kannst du dir mal den Code der APF-Webseite im SVN ansehen.
Viele Grüße,
Christian

hansjo
Beiträge: 38
Registriert: 02.03.2009, 16:22:16
Wohnort: München

Re: registry in taglib

Beitrag von hansjo » 05.05.2010, 00:27:22

warum generierst du die Navigation nicht direkt im Document-Controller, der die Navi auch ausgibt?
das hatte ich auch zunächst so implementiert und es hat (für die Navausgabe) funktioniert. Ebenso funktioniert es auch wenn ich im Haupt-Template-Controller (oder taglib) mein Nav-Objekt erzeuge und dann im Nav-Template-Controller daraus die Ausgabe des Menüs generiere. Aber mein Nav-Objekt ist nicht nur für die Ausgabe des Navmenüs gedacht, sondern kann noch mehr: z.B. weiss es welcher Content angezeigt werden soll und vielleicht möchte ich irgendwann den background des Headers von der aktuellen Menüwahl abhängig machen oder irgendwo einen breadcrumbs trail einbauen. Auch diese Infos stecken in meinem Nav-Objekt, da es Sessiondaten verwaltet und im Prinzip die Business-Logik für den gesamten Seitenaufbau beinhaltet. Daher soll es eben ganz am Anfang erzeugt werden (egal wie :? ). Mit 'Front-Controller' wollte ich mich bewusst bei diesem - meinem ersten konkreten Projekt (mit dem APF) nicht beschäftigen und erstmal die "einfachen" Dinge verstehen. Es ist sicher auch nicht notwendig.

Damit klarer wird wie ich versuche die Seite aufzubauen werde ich nun doch etwas code pasten und bitte um grobe beurteilung ob ich damit auf dem Holzeg bin oder wie ich es machen muss damit mein schönes Nav-Objekt gleich zu Beginn erzeugt wird und seine volle Wirkung entfalten kann:

index.php:

Code: Alles auswählen

...$page->loadDesign('sites::test::pres::templates',website');...
website.html:

Code: Alles auswählen

<core:addtaglib namespace="tools::myNavtree::taglib" prefix="my" class="navtree" />
<my:navtree /> <!-- hier soll also das Nav-Objekt erzeugt werden (egal ob per Taglib oder Doc-Controller) -->

<html>...
<tr><td>
 <core:importdesign namespace="sites::test::pres::templates" template="header" />
</td></tr>
<tr><td>
 <core:importdesign namespace="sites::test::pres::templates" template="menu" />
</td><td>
 <core:importdesign namespace="sites::test::pres::templates" template="content" />
 </td></tr>...
my_taglib_navtree.php:

Code: Alles auswählen

import('sites::test::biz','navItems');
import('core::session','SessionManager');

class my_taglib_navtree extends Document {
// var deklarieren
	function __construct(){
		parent::Document();
		$this->init();
	}

	private function init() {
		$this->reg = &Singleton::getInstance('Registry');
		$this->sessMgr = new SessionManager('sites::test::pres::templates');
		...
		// navTree Instanzieren
		$this->navTree = new navTree();
		...
		$this->reg->register('apf::core','navTree',$this->navTree);	
		...
header.html: ==> rein statisch

menu.html:

Code: Alles auswählen

<@controller
   namespace="sites::test::pres::documentcontroller"
   file="menue_controller"
   class="menue_controller"
@>
<ul><html:placeholder name="Nav" /></ul>
<html:template name="NavMenueLevel1"> <template:placeholder name="Link" /> </html:template>
<html:template name="NavMenueLevel2"> <template:placeholder name="Link" /> </html:template>

<html:template name="NavLinkLevel1"> <li><a href="./?<template:placeholder name="URL" />" title="<template:placeholder name="Title" />"><template:placeholder name="LinkText" /></a></li> </html:template>
<html:template name="NavLinkLevel2"> <li><a href="./?<template:placeholder name="URL" />" title="<template:placeholder name="Title" />"><template:placeholder name="LinkText" /></a></li> </html:template>
menue_controller.php:

Code: Alles auswählen

class menue_controller extends baseController {
	// var declaration
	function __construct(){
		$this->init();
	}

	private function init() {
		$this->reg = &Singleton::getInstance('Registry');
		// funtioniert hier einwandfrei (auch wenn navTree in controller von Website.html erzeugt wurde statt wie oben in taglib)
		$this->navTree = $this->reg->retrieve('apf::core','navTree');
		$this->selectionTree = $this->reg->retrieve('apf::core','currentSelectionTree');
		$this->selected = $this->reg->retrieve('apf::core','selected');
	}	

	function transformContent(){
		$this->setPlaceHolder('Nav',$this->__buildNav());
	}
	
	function ->__buildNav() {
		// placeholder iterativ befüllen
	}
	...
content.html:

Code: Alles auswählen

<core:addtaglib namespace="tools::myContent::taglib" prefix="my" class="content" />
<my:content initialContent="site_0" />
my_tagib_content.php

Code: Alles auswählen

class my_taglib_content extends Document {
	function __construct(){
		parent::Document();
	}

	function onParseTime(){
		$this->reg = &Singleton::getInstance('Registry');
		$this->navTree = $this->reg->retrieve('apf::core','navTree');
		echo printObject($this->navTree);
// und wie printObject zeigt gibt es in der Reg leider keinen 'navTree' :-(((
Nun ist das leider sehr länglich geworden, aber ich hoffe damit ist klar was ich mir vorstelle und vielleicht hilft eine Beurteilung ja auch anderen APF-Anfängern. Ich denke auch es ist ein Timingproblem und vermutlich müsste ich das Nav-Objekt als Taglib in einem child erzeugen, damit es eben als erstes erzeugt wird(?). Aber wie gesagt vielleicht ist ja auch mein ganzes Design bezüglich Nav-Objekt Blödsinn (auch wenn ich es bisher als praktisch empfunden habe)?

Jedenfalls schonmal vielen Dank - auch für die bisherigen Antworten!
Hansjörg
Zuletzt geändert von hansjo am 05.05.2010, 15:11:18, insgesamt 1-mal geändert.

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

Re: registry in taglib

Beitrag von dr.e. » 05.05.2010, 14:02:12

Hallo Hansjörg,

ich schau mir deinen Code bzw. deinen Aufbau mal genauer an. Ich denke jedoch, dass der Aufbau der Navigation dann in der index.php direkt vor dem Erzeugen der Page stattfinden muss. Es handelt sich dabei ja streng genommen um ein Model im Front-Controller-Style.

Melde mich mit Details...

Viele Grüße,
Christian
Viele Grüße,
Christian

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

Re: registry in taglib

Beitrag von dr.e. » 05.05.2010, 23:01:02

Hallo Hansjörg,

ich habe den geposteten Code stückchenweise zusammengesetzt und deinen Aufbau nachvollzogen. Ergebnis: es ist in der Tat ein Timing-Problem, da die onParseTime()-Methoden immer vor den onAfterAppend()- und vor den transform()-Methoden ausgeführt werden. Das bedeutet: wenn du in einer onParseTime() einen Wert in die Registry setzt (my_taglib_navtree), die Klasse, die das Auslesen zuständig ist (my_taglib_content), jedoch nach dieser erzeugt - und deren onParseTime() ausgeführt - wird, ist in der Registry natürlich noch kein Wert zu finden.

Das bedeutet: ein deterministisches Verhalten bekommst du nur dann, wenn du in unterschiedlichen Phasen agierst. Die Generierungs-Phase des APF-DOM-Baumes passiert dabei in den Methoden onParseTime() und onAfterAppend(). Anschließend wird der Baum transformiert, was sich in den Methoden transform() (bei Taglibs) und transformContent() (bei Document-Controllern) wiederspiegelt. Die Abfolge der Ausführungen visualisiert dir der BenchmarkTimer eigentlich sehr gut. Hier kannst du sowohl die Hierarchie deines Baumes sehen, als auch die Reihenfolge, in der die Methoden ausgeführt werden. Den Benchmark-Auszug habe ich dir angehängt:

Bild

In deinem Fall ist es besonders trickreich, denn dort wird die Instanz der Taglib my_taglib_content vor der Instanz von my_taglib_navtree erzeugt. Damit ist klar, dass in der selben Phase das Auslesen vor dem Schreiben passiert. Als Lösung sollte daher das Auslesen in die Transformations-Phase verlegt werden, sprich entweder in die Methode my_taglib_content::transform() oder menue_controller::transformContent().

Goldene Regel für die Implementierung von dynamischen Inhalten ohne Front-Controller sollte also immer sein, die wirklich relevanten Inhalte, die schon zu Beginn für alle Komponenten der GUI (Controller, Taglibs) verfügbar sein sollen, in der index.php zu füllen. So bist du sicher, dass du schon in der Generierungs-Phase auf diese zugreifen kannst. An Hand des Benchmark-Baumes kannst du dir aber immer klar machen, wann eine Komponente ausgeführt wird um einen evtl. Timing-Fehler sofort zu sehen. Aber auch ohne index.php: sofern du also die Erzeugung der Inhalte in die Generierungs-Phase und die Ausgabe in die Transformations-Phase legst, wird das immer klappen.

Damit du ein ungefähres Beispiel der Vorgehensweise hast, habe ich den lokal zum Testen verwendeten Code zusammengepackt und unter http://media.adventure-php-framework.or ... hansjo.zip zur Verfügung gestellt. Zum Ausprobieren einfach lokal im Document-Root des Webservers entpacken und entsprechende URL aufrufen. Die Ausgabe zeigt die Inhalte, die in die Registry geschrieben wurden und eine Benchmark-Ausgabe (wie oben).

Ich hoffe, damit wird die Arbeit des Page-Controller hinsichtlich des Timing-Modells etwas klarer und du kommst weiter. Es hört sich sicher zunächst kompliziert und verwirrend an, das Konzept hat jedoch einige wirklich gravierende Vorteile. :)

Viele Grüße,
Christian
Viele Grüße,
Christian

hansjo
Beiträge: 38
Registriert: 02.03.2009, 16:22:16
Wohnort: München

Re: registry in taglib

Beitrag von hansjo » 06.05.2010, 00:05:46

hi Christian,

tausend dank für deine unsägliche Mühen!!! ich bin tief beeindruckt und habe deine Ausführungen mit stauenden Augen gelesen. Ich muss das jetzt erstmal verdauen (verstanden habe ich es soweit schon) aber du hast dir nun sicher erstmal Ruhe vor mir bis ich mit weiteren Fragen komme. Ich denke ich werde das in der bootstrap einbauen aber natürlich schaue ich mir auch noch deinen Code an etc. Jedenfalls habe ich wieder einiges über die Arbeitsweise des APF gelernt und muss eh sagen, dass die Begeisterung über die Möglichkeiten immer weiter wächst, je mehr man versteht.

Mit meinem Vorgehen per zentralem Nav-Objekt habe ich offenbar "ein Monster" geschaffen ;) aber ich bin doch auf meine Idee so stolz .. es hat den Hintergrund dass ich alles über einen einzigen URL-parameter 'id' und natürlih sessiondaten managen will und da macht es m.E. Sinn einmal zentral zu ermitteln was der user zu sehen bekommt - mal sehen was noch daraus wird.

Eine Frage hätte ich doch noch - du hast von 'Breakpoints' gesprochen und da wollte ich fragen was für eine IDE du verwendest bzw. empfehlen kannst? Ich arbeite sehr gerne mit PHPEclipse und da habe ich mir mal den 'dgb -Debugger' installiert, aber der funktioniert nur leidlich und beim APF ist er sofort abgeraucht (das war ihm zu viel :lol: ==> eine einfach Antwort reicht.

So denn - nochmal Danke für den super support!
Hansjörg

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

Re: registry in taglib

Beitrag von dr.e. » 06.05.2010, 08:02:28

Hallo Hansjörg,

etwas hatte ich gestern noch vergessen zu sagen: die von dir in den Klassen definierte init()-Methode sollte eigentlich zu einem Fehler der Art
Fatal error: Access level to my_taglib_navtree::init() must be public (as in class coreObject) in D:\Apache2\htdocs\www\test.de\thread_333\apps\tools\myNavtree\taglib\my_taglib_navtree.php on line 26 Call Stack: 0.0009 51096
1. {main}() D:\Apache2\htdocs\www\test.de\thread_333\index.php:0 0.0198 988144
2. Page->loadDesign() D:\Apache2\htdocs\www\test.de\thread_333\index.php:4 0.0200 994400
3. Document->loadDesign() D:\Apache2\htdocs\www\test.de\thread_333\apps\core\pagecontroller\pagecontroller.php:1145 0.0206 995544
4. Document->__extractTagLibTags() D:\Apache2\htdocs\www\test.de\thread_333\apps\core\pagecontroller\pagecontroller.php:1328 0.0221 1004464
5. core_taglib_addtaglib->onParseTime() D:\Apache2\htdocs\www\test.de\thread_333\apps\core\pagecontroller\pagecontroller.php:1503 0.0222 1004728
6. Document->addTagLib() D:\Apache2\htdocs\www\test.de\thread_333\apps\core\pagecontroller\pagecontroller.php:1819 0.0222 1006248 7. import() D:\Apache2\htdocs\www\test.de\thread_333\apps\core\pagecontroller\pagecontroller.php:1279
führen. Das hat den Hintergrund, dass eine gleiche Methode bereits in der Klasse coreObject definiert ist. Diese wird üblicherweise dann verwendet, wenn das Objekt mit dem Service-Manager initialisiert wird. Hier schickt es sich den Code aus der Methode einfach in den Konstruktor zu kopieren, dann klappt das ebenso.
Ich muss das jetzt erstmal verdauen (verstanden habe ich es soweit schon) aber du hast dir nun sicher erstmal Ruhe vor mir bis ich mit weiteren Fragen komme.
Kein Problem, dafür bin ich da. ;)
Jedenfalls habe ich wieder einiges über die Arbeitsweise des APF gelernt und muss eh sagen, dass die Begeisterung über die Möglichkeiten immer weiter wächst, je mehr man versteht.
Das freut mich. Das APF ist zugegeben nicht so ganz einfach aufgebaut - gerade das Page-Controller-Timing-Modell ist ein Brett -, aber die Möglichkeiten sind dadurch immens. Wir werden in der Zukunft auch versuchen, gerade die häufig diskutierten Themen (z.B. dieses hier) noch mehr mit Artikeln und Tutorials zu belegen. In der Zwischenzeit einfach im Forum fragen.
Mit meinem Vorgehen per zentralem Nav-Objekt habe ich offenbar "ein Monster" geschaffen ;) aber ich bin doch auf meine Idee so stolz .. es hat den Hintergrund dass ich alles über einen einzigen URL-parameter 'id' und natürlih sessiondaten managen will und da macht es m.E. Sinn einmal zentrak zu ermitteln was der user zu sehen bekommt - mal sehen was noch daraus wird.
Die Idee ist auch definitiv etwas, worauf du stolz sein kannst, denn sie ist sehr gute! Es ist meiner Meinung nach eine wirklich saubere HMVC-Implementierung, in der eine Klasse als Model für verschiedene H(M)VC-Einheiten genutzt wird und den Status der Applikation zentral zur Verfügung stellt. Und das ist gut!
Ach eine Frage hätte ich noch - du hast von Breakpoints gesprochen und da wollte ich fragen was für eine IDE du verwendest bzw. empfehlen kannst? Ich arbeite sehr gerne mit PHPEclipse und da habe ich mir mal den 'dgb -Debugger' installiert, aber der funktioniert nur leidlich und beim APF ist er sofort abgeraucht (das war ihm zu viel) ==> eine einfach Antwort reicht.
Unter http://adventure-php-framework.org/Seit ... -Werkzeuge sind Werkzeuge beschrieben, dir für die Entwicklung empfohlen werden. Ich persönlich nutze NetBeans IDE zusammen mit Xdebug und einer lokalen Apache+PHP-Installation. Das funktionierte bisher tadellos und auch der Debugger ist selten abgebrochen. Sicher ist das debuggen von komplexen Baum-Strukturen nicht einfach, aber mit Xdebug und NetBeans IDE hat das bisher immer geklappt. Es gibt auch auf der Seite http://wiki.netbeans.org/HowToConfigureXDebug ein gutes Tutorial, wie das aufuzsetzen ist, damit die Integration mit NetBeans IDE funktioniert. Solltest du dazu Support benötigen, kann ich dir mal meine Konfiguration posten.
Viele Grüße,
Christian

hansjo
Beiträge: 38
Registriert: 02.03.2009, 16:22:16
Wohnort: München

Re: registry in taglib

Beitrag von hansjo » 06.05.2010, 08:12:51

definierte init()-Methode sollte eigentlich zu einem Fehler der Art (...) führen
...tut es aber nicht weil die Methode bei mir tatsächlich 'initNav' heisst - ich hatte das etwas gekürzt...
Die Idee ist auch definitiv ... sehr gut
Danke!
bis dahin bin ich bisher noch nicht vorgedrungen. Ich werde mir das bei Gelegenheit mal ansehen

Hansjörg

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

Re: registry in taglib

Beitrag von Screeze » 06.05.2010, 14:35:09

Anmerkung am Rande, bevor du evtl. stundenlang verzweifelst suchst wie ich:
Die aktuelle version von Xdebug funktioniert nicht richtig mit Windows 7, auf jedenfall nicht mit der 64 bit version (bei 32 bit bin ich nicht sicher). Da bricht der debugger laufend mit ner socket exception ab. Soll allerdings bald behoben sein. (Falls du win 7 hast)

hansjo
Beiträge: 38
Registriert: 02.03.2009, 16:22:16
Wohnort: München

Re: registry in taglib

Beitrag von hansjo » 06.05.2010, 14:49:53

(Falls du win 7 hast)
nicht auf meinem Entwicklungsrechner (da verlasse ich mich auf Bewährtes XP). Aber danke - gut zu wissen!

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

Re: registry in taglib

Beitrag von dr.e. » 08.05.2010, 14:57:05

Hallo zusammen,

zum Timing-Modell des Page-Controller habe ich im Wiki unter http://wiki.adventure-php-framework.org ... Controller noch eine Seite mit ergänzenden Informationen angelegt. Diesen Eintrag habe ich wegen der Wichtigkeit der Thematik nach FAQs verschoben.
Viele Grüße,
Christian

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast