View Issue Details

IDProjectCategoryView StatusLast Update
0000197Adventure PHP FrameworkNeues Feature // New Featurepublic2018-08-26 00:31
ReporterChristianAchatzAssigned ToChristianAchatz 
PrioritynormalSeverityfeatureReproducibilityN/A
Status resolvedResolutionfixed 
Product Version3.0 
Target VersionFixed in Version 
Summary0000197: Proposal for condition tags
DescriptionConcept for
* Condition tags in templates (if, when, ...)
* Change of timing model to be able to support condition validation in templates to be supported by controllers
TagsNo tags attached.
Codereferenz: ([Datei]:[Zeile])
Namespacecore

Activities

jwlighting

2014-06-01 17:45

administrator   ~0000369

Hallo Christian,

warum möchtest du die m.M.n. sinnvolle Kapselung der Logik im Controller aufgeben?
Ich kenne zwar auch genügend Anwendungsfälle, bei denen ich mir solche Tags gewünscht hätte, weil sie praktisch sind - konnte aber im nachhinein auch immer einsehen, dass ich mit einem Controller besser aufgestellt bin.

Lass uns das doch, gerne auch im Forum, mal diskutieren.

Jan

ChristianAchatz

2014-06-08 13:24

administrator   ~0000378

Hallo Jan,

bei PAYBACK haben wir festgestellt, dass oft zu viel Logik im Controller stattfindet bzw. die Controller überfrachtet sind. Für einfache, bedingte Ausgaben (fast ausschließtlich für den View interessant - z.B. für CSS-Klassen) musst du aktuell einen Tag schreiben oder den Controller bemühen. Gerade bei der Implementierung eines multi-Brand PORTALs ist das bei sehr vielen Funktionen und Konfigurations-Optionen sehr oft lästig.

Grundsätzlich aufgeben möchte ich die Trennung nicht, dagegen verweigern halte ich jedoch mit der Erfahrung bei PAYBACK für die falsche Lösung.

Das Proposal soll ja auch erst mal eine Idee entwickeln, weniger eine konkrete Umsetzung forcieren. Die Umsetzung der erweiterten Templating-Syntax war ja zunächst auch fast zu "revolutionär", bringt aber enorme Vorteile in der Gestaltung von Templates.

Diskutieren über Vorschläge, das Proposal an sich (wenn es mal steht) möchte ich mit euch definitiv. Da führt kein Weg dran vorbei - schon alleine um eure Erfahungen und euer Feedback sowie Zuspruch und Ablehnung zu berücksichtigen. Mir ist es sehr wichtig mit euch zusammen eine Entscheidung zu treffen.

jwlighting

2014-06-08 16:20

administrator   ~0000379

Hallo Christian,

vielen Dank für dein Feedback.
Für mich klingt das ein bisschen nach dem Unterschied zwischen Theorie und Praxis ;)

> zu viel Logik im Controller stattfindet bzw. die Controller überfrachtet sind. Für einfache, bedingte Ausgaben (fast ausschließtlich für den View interessant - z.B. für CSS-Klassen) musst du aktuell einen Tag schreiben oder den Controller bemühen.

Hast du ein konkretes Beispiel zur Hand? Kann ich mir gerade schlecht vorstellen.


> Die Umsetzung der erweiterten Templating-Syntax war ja zunächst auch fast zu "revolutionär", bringt aber enorme Vorteile in der Gestaltung von Templates.

Was meinst du hier genau? Kann mit "erweiterte Templating-Syntax" grad nichts anfangen ;)

> Mir ist es sehr wichtig mit euch zusammen eine Entscheidung zu treffen.

Machen wir! ;)

ChristianAchatz

2014-06-09 19:51

administrator   ~0000380

Hallo Jan,

> Hast du ein konkretes Beispiel zur Hand? Kann ich mir gerade schlecht vorstellen.

Nehmen wir an, du hast folgendes HTML:

<section class="article ${cssClass}">
   <h2>${article->getTitle()}</h2>
   

${article->getText()}


</section>

Um die richtige(n) CSS-Klasse(n) für einen kleinen, mittleren und großen Artikel zu evaluieren, braucht es Logik im Controller, die an sich "nur" die Formatierung betrifft. Hätte ich im Template die Möglichkeit "klein", "mittel" und "groß" in eine CSS-Klasse zu mappen (z.B. mit einem if-Tag o.ä.), könnte ich mich im Controller auf die wesentlichen Punkte konzentrieren.

Ferner wird bei PAYBACK an einigen Stellen ein Template für mehrere Brand-spezifische Ausgaben genutzt (um den Grad der Wiederverwendbarkeit hoch und damit die Produktionskosten niedrig zu halten). Auch hier wäre es von Vorteil, wenn ich Entscheidungen für die Ausgabe-Formattierung nicht im Controller treffen müsste.

> Was meinst du hier genau? Kann mit "erweiterte Templating-Syntax" grad nichts anfangen ;)

Schau dir mal http://adventure-php-framework.org/Seite/047-Templates#Chapter-3-Erweiterte-Template-Funktionen an. :)

jwlighting

2014-06-09 21:09

administrator   ~0000381

> Schau dir mal http://adventure-php-framework.org/Seite/047-Templates#Chapter-3-Erweiterte-Template-Funktionen [^] an. :)

Oops 8), da hab ich ja ganz schön was verpasst.
Dann fehlt da auch noch ein Iterator, mit dem ich die Array-Elemente (-> http://adventure-php-framework.org/Seite/047-Templates#Chapter-3-2-1-Listen-Zugriff ) durchgehen kann.

Danke!

ChristianAchatz

2014-06-11 16:45

administrator   ~0000384

Letzteres könnte evtl. durch den Iterator selbst (dort funktioniert der Array- und Objekt-Access mit der erweiterten Template-Syntax schon) oder durch einen eigenen foreach-Tag gelöst werden. Das können wir gerne in den POC inkludieren.

ChristianAchatz

2018-08-26 00:31

administrator   ~0000863

Implementation of extended templating syntax and <cond:placeholder /> as well as <cond:template /> sufficient. Thus closing this issue.

Issue History

Date Modified Username Field Change
2014-05-28 19:15 ChristianAchatz New Issue
2014-06-01 17:45 jwlighting Note Added: 0000369
2014-06-08 13:24 ChristianAchatz Note Added: 0000378
2014-06-08 16:20 jwlighting Note Added: 0000379
2014-06-09 19:51 ChristianAchatz Note Added: 0000380
2014-06-09 21:09 jwlighting Note Added: 0000381
2014-06-11 16:45 ChristianAchatz Note Added: 0000384
2018-08-26 00:31 ChristianAchatz Note Added: 0000863
2018-08-26 00:31 ChristianAchatz Assigned To => ChristianAchatz
2018-08-26 00:31 ChristianAchatz Status new => resolved
2018-08-26 00:31 ChristianAchatz Resolution open => fixed