PHP rocks! wünscht allen Mitgliedern einen guten Rutsch ins neue Jahr 2017 !!!
Hinweis: Das Forum zieht um! Um keine Datenverluste zu haben, schalten wir zwecks Übernahme der Daten das Forum am Sonntag, den 24.04.2016 um ca. 21:00 Uhr offline und passen anschliessend die DNS-Einträge an.
www.php-rocks.de wird euch dann nach den Aktualisierungen der DNS-Server wieder wie gewohnt uneingeschränkt zur Verfügung stehen.
Danke für euer Verständnis!

Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Objekte aus Klassen instanziieren
#11
Scarabaeus schrieb:Sowas würde ich aufgrund des EVA Prinzipes nicht wirklich machen wollen, es sein denn dass deine Daten, deine Templates und dein Parser alles zusammen in ein neues "Dokument" überführen und dann die Ausgabe erfolgt (ähnlich XSLT).
Die einzelnen Templates ( Header, Content, Footer, u.a. ) werden zu einem HTML-Dokument zusammengeführt und mittels Parser endgültig verarbeitet.
Es mag bessere Umsetzungen geben, aber in Bezug auf EVA sehe ich da jetzt keine großartigen Konflikte, weil das quasi nichts anderes ist, was Template-Systeme á la Twig oder Smarty auch machen. Das use-Tag ist auch nur eins von ein paar. Ich verarbeite auf die Weise auch foreach-Loops o.ä.:
Code:
<dp:foreach item="$Item" in="$Gallery">
    <div class="galleryitem">
        <a href="{html.path.images}galerien/$Item.FolderName/$Item.ImageName"><img src="{html.path.images}foobar.jpg" alt=""></a>
    </div>
</dp:foreach>
Was mich zu dieser Vorgehensweise mit <dp:use geführt hat, war das Widerstreben, ständig ein Mapping vorhalten zu müssen, auf welcher Seite ich nun welchen Controller benötige.
Bspw. geht es mir um einen GalleryController, der wie der Name schon sagt nur in einer Galerie Verwendung finden muss. Wozu soll ich den Controller also erst instanziieren bzw. laden, wenn er auf allen anderen Seiten eh nicht benötigt wird?!

Der nächste logische Schritt wäre gewesen, ein Mapping vorzuhalten, das Informationen darüber enthält, auf welchen Seiten der GalleryController verwendet werden muss. Das empfand ich persönlich allerdings ( da es um mehrere Controller geht, die ähnliche Aufgaben haben, von denen man die Ergebnisse gleichermaßen verarbeiten kann ) als nervend und habe mir überlegt, wie ich das in die Templates implementieren könnte.

Das funktioniert soweit gut für mich, auch wenn es wie gesagt bessere Lösungen geben mag.
Ich arbeite halt ungern mit großen Frameworks, wenn es sich um kleine Projekte, wie FeWo o.ä. handelt... Wink


mermshaus schrieb:Ich sehe nicht so recht, was daran besser ist als an:
Die Variante, die Du vorschlägst hatte ich zwischenzeitlich auch schon mal, gehörte aber leider zu denen, die einen Konflikt mit dem Autoloader hatten.
Frag mich nicht, wo das Problem liegt, aber ohne Autoloader funktioniert die Variante bei mir einwandfrei, mit leider nicht.

Gruß Arne
Antworten
#12
(24.05.2016, 00:30)Arne Drews schrieb:
mermshaus schrieb:Ich sehe nicht so recht, was daran besser ist als an:
Die Variante, die Du vorschlägst hatte ich zwischenzeitlich auch schon mal, gehörte aber leider zu denen, die einen Konflikt mit dem Autoloader hatten.
Frag mich nicht, wo das Problem liegt, aber ohne Autoloader funktioniert die Variante bei mir einwandfrei, mit leider nicht.

Ich würde noch mal versuchen, den Klassennamen fully qualified anzugeben, falls du das nicht schon getan hast. Wenn es um Klassen im globalen Namensraum geht, also zum Beispiel auch so:

PHP-Code:
$fqcn '\\' $assembly;
$obj = new $fqcn
Antworten
#13
Das'n Versuch wert... Mache ich nachher mal, danke!
Antworten
#14
Öhöm... Getreu dem Motto: "Kaum macht man's richtig, funktioniert es", haut es natürlich so hin, wie ihr beide auch schon gesagt habt:
PHP-Code:
$o = new $assembly->value;
$oParser->ProcessLoop$o->Identifier$o->GetData() ); 
Mein Fehler lag darin, dass $assembly vom Typ DOMAtrribute ist und ich hatte die ganze Zeit erfolgreich das ->value ignoriert...

Danke für eure Hinweise, eine ReflectionClass ist hier tatsächlich unnötig.

Schöne Grüße
Arne
Antworten


Gehe zu: