Template + while-Schleife

[dr.e.]

Hallo Slava,

Auch zugiff auf ein XML tag hasst du bei meiner Template nur über die zusatzfunction, die als optionaler parameter übergeben wird oder auch wie bei den anderen Templaten, in dem du ausgabe erst zwischenspeicherst.

Mit Zugriff auf XML meine ich, dass ich innerhalb eines Templates per XML-Tag an definierter Stelle ein weiteres einbinden kann. Das geht bei mir so:

<core:importdesign namespace="" template="" />

Somit kann ich allein mit der Erweiterung eines Templates ein weiteres, bzw. eine weitere Funktion einbinden. Hier wurde nach dem Composite-Pattern vorgegangen, so dass man eine beliebige Schachtelungstiefe erzeugen kann. Praktischer Anwendungsfall: gemeinsames Menü wird in die Seite eingebaut.

Wenn du hierzu mal eine Demo oder Anwendung sehen möchtest, kann ich dir gerne was zukommen lassen. Sprich mich einfach mal drauf an!

Erste Frage:
Ich versuche gerade viel zu oft Shared Memory für chacen einzusetzen.

SharedMemoryCache sind nicht einfach zu handhaben, da PHP Reauestgetrieben ist. Somit kommt der Benutzer immer nur bei einem Request "vorbei". Man sollte sich nun überlegen, welche Daten man im Memory vorhält, da die Requests oft zu unterschiedlich sind, als dass sich das lohnen würde. Ich persönlich setze das nur für gemeinsame Komponenten wie MySQL-Handler oder andere Business-Komponenten ein, die ich aber dediziert auswähle und SessionSingleton instanziiere. Den Rest erzeuge ich immer zur Laufzeit (=Requestzeit), da sich der Aufwand performance-technisch nicht lohnt. Damit solltest du auch keine RAM-Probleme bekommen. Man kann PHP ohnehin restriktieren. Auf einem LINUX-System kann man dann zudem dem PHP- oder Apache-Prozess beim Starten noch ein ulimit mitgeben.

Zweite Frage:
Ist es sinnvoll für die sessionführung nicht dateien sondern Shared Memory zu benutzen?

Das ist nur sinnvoll, wenn du Objekte in der Session halten möchtest, denn das geht mit PHP per se nicht. Solltest du einen SingletonSessionHandler haben, der dir das Objekt automatisch serialisiert / deserialisiert und in die Session schreibt / aus der Session holt, brauchst du auch das nicht unbedingt. Es ist zwar sicher schöner, weil man sich das serialisieren / deserialisieren spart (kostet einiges an Zeit!), aber bei kleinen Sessions ist das noch nicht relevant.

Weitere Fragen beantworte ich gerne.

[Slava]

hi dr.e
erst mal danke für die Tipps die du mir gegeben hast.
vermutlich musss man doch fall zum fall unterscheiden und erst nach dem testen sich für eine oder andere art von cache entscheiden. vermutlich werde ich weiter hin schared memory benutzen, aber nur für die gemeinsame komponente die aufwendig im aufbau sind aber kleine und wenige Ausgaben erzeugen, also sparsam wie möglich.
mit shard memory session muss ich mir noch überlegen und ein wenig testen um zu einer Entscheidung zu kommen. Aber eine Sache ist mir klar, dass die geschwindigkeit von shared memory mindestens 5 mal schneller als wenn man mit dateien arbeitet.

zu deiner template will ich nur zum besserem Verständnis eine Frage stellen. wie unterscheidet sich dein Einsatz :
<core:importdesign namespace="" template="" />
zbs von include in smarty? bzw. welche Vorteile, bietet es in Vergleich zu einer include von zusätzlicher template?
Danke. (und wie immer entschuldige ich mich für mein deutsch)

[dr.e.]

Hallo Slava,

zu deiner template will ich nur zum besserem Verständnis eine Frage stellen. wie unterscheidet sich dein Einsatz :
<core:importdesign namespace="" template="" />
zbs von include in smarty? bzw. welche Vorteile, bietet es in Vergleich zu einer include von zusätzlicher template?

Hmm, das ist etwas schwierig, da ich Smarty nicht so genau intern kenne, wie ich meine Tools kenne. Ich versuch es aber trotzdem mal zu beschreiben:
Grundsätze meines Handelns und damit Programmieren sind

- Trennung von Design und Inhalt
- MVC
- 3-Schicht-Architektur
- Kapselung in Service-Layer

Um diesen Ansprüchen gerecht zu werden, muss auch die Präsentations-Schicht komplett generisch aufgebaut sein. Hierzu habe ich einen generischen PageController implementiert, dem ich ein Template geben kann und er baut für mich den Objektbaum (=eigenes, von mir deklariertes DOM) auf. Das bedeutet, dass ein <core:importdesign /> an der eingesetzten Stelle einen Kindknoten des aktuellen Templates im DOM erzeugt. Damit kann man einen beliebig tief geschachtelten Objekt-Baum aufbauen. Jedes Objekt (es sind PHP-Objekte) hat bestimmte Eigenschaften und je nach Tag auch unterschiedliches Verhalten. Zu jedem Tag kann man innerhalb des Templates einen Controller (=DocumentController) definieren, der eine bestimmte Ausgabe-Logik gemäß MVC besitzt. Ist der Objektbaum komplett aufgebaut, kann man die komplette Seite per

$Page->transform();

transformieren und ausgeben. Transformieren heißt in diesem Fall, dass der PageController rekursiv den DOM-Baum durchgeht und bei jedem Blatt nachsieht, ob ein DocumentController existiert, wenn ja, diesen ausführt, und sich zu guterletzt den Inhalt des Objektes wiederum per Aufruf der Methode transform() ausgeben lässt und rekursiv in die Vater-Knoten einsetzt.

Bei dieser Vorgehensweise hast du den Vorteil, dass du eine Applikartion (z.B. Kontaktformular) komplett eigenständig entwickeln kannst und dieses später mit einem <core:importdesign /> in der Anwendung an beliebiger Stelle einbinden kannst.

Neben den genannten Tags bringt das Framework auch beliebige andere Tags mit, die man einbauen und verwenden kann. Beispiel sind hier die Formular-Tags. Mit diesen kann man ein komplettes Formular mit Validatoren etc. komplett in einem Template definieren, ohne auch nur eine Zeile PHP schreiben zu müssen. Auf die einzelnen Tags kann man später im DocumentController natürlich zugreifen und kann sich dort z.B. eine Referenz auf ein Select-Feld holen und dieses mit Werten aus der DB befüllen. Anderer Anwendungsfall mit Formularen: Wenn man ein Formular anbietet, so möchte man dieses nur abschicken, wenn es auch korrekt ausgefüllt ist. Dies erledigt das Formular bereits selbst beim Aufbau des DOMs. Im DocumentController kannst du dann einfach per

<?php
$Form = &$this->__getForm('MyForm');
if($Form->get('isValid'){
   ...
}
else{
   ...
}
?>

prüfen, ob dein Formular korrekt ausgefüllt wurde. Wenn nicht, kannst du bereits im Formular Validatoren (Text und CSS) definieren, die dann anspringen. Ist es valide, so kannst du eine entsprechende Logik zum Versand implementieren.

Das Beispiel diskutiere ich gerade mit Promethaeus. Du kannst es unter http://development.promadesign.com/i...p?cont=contact ansehen. Das Design bitte vernachlässigen, es geht um die Funktion Solltest du mehr wissen wollen, kann ich das gerne mal zeigen - ich hab Urlaub. Hatte sowieso vor, die Sourcen bereitzustellen und im Forum zu diskutieren, wenn du magst, können wir das sehr bald (ich bin gerade noch am Refactoring einiger alter Komponeten) tun.

Danke. (und wie immer entschuldige ich mich für mein deutsch)

Kein Problem.Was für ein Landsmann bist du eigentlich?

[Slava]

<<Kein Problem.Was für ein Landsmann bist du eigentlich?>>
meine Muttersprache ist russisch. da ich erst mit 27 angefangen habe deutsch zu lernen, ist der Fehler nicht mehr zu beheben .
Ich bin seit 2 Jahren eingebürgert worden, und jetzt hat Deutschland noch einen Analphabet bekommen .

Ich kenne deine Template-system nicht, aber ganz spontan ist mir eingefallen, dass man nicht unbdingt zur laufzeit jedes mal Template über DOM aufgebaut sein muss, sondern der DOM-Object selbst in einem serialisiertem zustand getrennt halten. bei der Template-aufruf könnte man die lätzte veränderungsdatum von Template mit veränderungsdatum von DOM-Object vergleichen und erst bei einer Abweihung DOM-Object überschreiben. sonnst, wenn keine Abweichung gibt wirst du bestimmt bei derserialisieren von deinem DOM-Object mehr resource sparen, als wenn du jedes mall deine Template mit DOM parsen wirst.

alles was ich eben geschrieben habe ist eine spekulation da ich nicht wirklich deine Template kenne. also betrachte das als lautes selbstgesprech

[dr.e.]

Hallo Slava,

Ich bin seit 2 Jahren eingebürgert worden, und jetzt hat Deutschland noch einen Analphabet bekommen Embarassed.

Quatsch, das ist kein Problem für mich. Wir verstehen uns schon

Thema Serialisierung:
Hier habe ich ein paar Tests gemacht so etwas zu realisieren. Sprich ich rufe eine Seite auf und schau nach, ob für diese bereits ein Objekt der Form wie ich sie brauche besteht. Das ist aber implementierungstechnisch sehr schwer, weil die Vergleichbarkeit von Objektbäumen per se nicht wirklich einfach ist. Performance-Tests haben mir darüber hinaus Recht gegeben, dass sich der Ansatz nicht wirklich lohnt. Statt dessen verwende ich für wichtige Teile der Anwendung Caching. Ich kenne dabei drei Arten von Caching:

- Statement-Caching
- Objekt-Caching
- HTML-Content-Cache

Das bedeutet folgendes:

- Jedes MySQL-Statament wird nach md5-Schlüsseln gecached und bei einem erneuten Aufruf aus dem Cache bedient. Diese Form ist nicht so wichtig und wird daher nur bei größeren Anwendungen, in denen ein DataMapper im Einsatz ist.
- Fertige Objekte (zumeist Daten-Objekte) werden serialisiert um vom CacheManager abgelegt. Bei einem Zugriff auf die Datenschicht werden die Daten bereits im Fertigen Domain-Object-Modell deserialisiert und zurückgeliefert und müssen nicht erst zusammengesetzt werden.
- Für fertige Anwendungsteile (wie oben beschrieben) werden die HTML-Fragmente des Contents gecached, so dass eine bereits aufgerufene Seite immer aus dem HTML-Cache kommt und damit verdammt schnell ist.

Ich habe die Erfahrung gemacht, dass das Cachen des Contents der Seite schon einiges ausmacht. Hier messe ich bei der Bildergalerie ca. 500ms Ausführungszeit (DB-Zugriff, Mappen der Objekte, Darstellung des Inhalts) im ungecachten Zustand und ca. 90ms im gecachten Zustand. Cache ich noch das Menü und den Header-Bereich (mehr bleibt ausser dem Content-Bereich nicht), so komme ich vielleicht unter 80ms, was nicht wirklich den Aufwand lohnt. Das sind übrogens Werte von meinem Highperformance-Notebook. Auf einem ordentlichen Humpen geht das natürlich schneller
Im High-Performance-Umfeld (Server der Messe München) verfahren wir nach dem selben Prinzip und haben ein paar mehr Zugriffe. Hier werden auch Statements, komplette Objekte und HTML-Fragmente lazy gechached und das Konzept geht auf.

alles was ich eben geschrieben habe ist eine spekulation Smile da ich nicht wirklich deine Template kenne. also betrachte das als lautes selbstgesprech

Kein Problem, ich finde die Diskussion gut. Unter http://media.adventure-php-framework...l_webseite.zip habe ich ein Beispiel zusammengestellt, das zeigt, wie das grob funktioniert. Einfach in den lokalen Webserver kopieren und die index.php aufrufen. Solltest du Fehler bekommen, sag Bescheid. Unter "Hilfe" findest du eine Anleitung, wie die Seite aufgebaut ist. Die Anleitung wird demnächst noch aktualisiert, die neuen Quellen (TagLib-Dokumentation) kann ich dir aber schon zuschicken, wenn du möchtest.

So long,

[dr.e.]

Hallo GN,

konntest du dein Problem nun lösen? Anregungen für Verbesserungen konntest du den letzten x Beiträgen ja entnehmen.