@Strat:

Quote

oder so aehnlich, was ich als Beispiel zwischen Programmlogik-IFs und Layoutlogik-IFs brachte, also wieso ich manche IFs im Template sehr hilfreich finde.

Ja. Ich meine, ein [% INCLUDE foo.html %] hat bisher noch jeder
Designer den ich kannte (der nicht vor HTML Angst hatte) noch
hinbekommen bzw. verstanden. Ein $myfile = 'foo.html';
$whatever->render( $myfile ); o.ä. ist für mich Programmcode.
Da hat der Designer nicht rein zu müssen.

Quote

Da Du von ASP auch keine Ahnung hast, lassen wir das Thema lieber gleich.

Ähem. Versuchs doch mal in *Perl*? Oder sage mir, was die zwei
nichts-aussagenden Beispiele von dir (wie üblich) sagen sollen?

Aber gut, ich nehme deine Kapitulation natürlich gern an.

Quote

Schneller geparst

Cachen. Hardware ist außerdem inzwischen recht günstig, und
ich hatte mit Catalyst, TT, DBIC etc. die alle für einzelne
Requests angesprochen werden noch keine Probleme. Vielleicht
wären deine HTML Dateien etwas kleiner, wenn du sie von Hand
schreiben würdest?

Abgesehen davon: Die Geschwindigkeit die (eigentlich nicht)
erzielt wird steht in keinem Verhältnis zum Wartungsaufwand
einer Lösung die das Template nicht auslagert. Meine Meinung.

Quote

Einfacher zu verwalten und zu ändern

Meinst du? Von mir bekommt der Designer eine Referenz, welche
Resource welche Daten bereitstellt. Das heißt, er weiss, wenn er
[% IF user.is_admin %] sagt, sieht das dann nur der Admin. Das
ist um *einiges* einfacher zu verwalten und zu ändern als wenn
die VIEWlogik im Perlcode stehen würde.

Nicht nur das, der Designer kann nichtmal großartig etwas
kaputtmachen! Er kann Fehler auslösen, ja. Aber er kann keine
Daten zerstören, weil es aufwendiger ist, Schreibzugriff zu
bekommen (aus Versehen). Und trotzdem kann er sich um das
gesamte Frontend kümmern.

Was für Möglichkeiten das zB für Tests gibt, muss ich wohl nicht
anführen. Man stellt sich vor, man übergibt im Testlauf dem
Template einfach einen gemockten Stash, und prüft das, was
rauskommt.

Bei deiner Variante frage ich mich allerdings, was der Designer
überhaupt macht. Ich meine, von XML/XHTML/HTML/CSS/JS etc.
scheint er ja keine Ahnung haben zu müssen. Nach
Usability/Accessibility etc. frag ich garnicht mal erst. Kann es
sein, dass du der Designer bist? Das würde einiges erklären.

Quote

Es müssen z. B. nicht ganze Textblöcke mit zig If's verschoben werden sondern nur das einzelne Tag.

Ja, um eine *Position* zu ändern. Eine andere Position hat
nichts mit der Logik zu tun. Für *die* brauchst du dann nämlich
wieder einen Perlentwickler.

Das heißt auch, dass du einen Perlentwickler brauchst, um das
Interface an einen Kunden anzupassen. Obwohl oftmals wohl
schon ein Designer (ein echter) mit TT* Buch ausreichen würde.

* Ich schreibe immer TT weil ich es selbst verwende.
Alternativen wie HTC, HT etc. sind da nehm ich an genauso
flexibel.

Quote

Logik extern - Einfach besser

Langsam bin ich mir *sicher* dass du ein Troll bist. Du sollst
genau *dafür* Argumente bringen. Und du bringst das, was du
argumentativ darlegen sollst, selbst als Argument ein? Achso,
"Einfach besser" ist ein Argument? Möchtest du, dass ich jetzt
"Yes, my Master!" schreie, mir das Shirt vom Leib reisse und aus
Ehrfurcht Sepukku begehe?

Quote

(Bei Deiner Version ist Gesamt Layout+ Logik verschmolzen.)

+Layoutlogik, ja. Ein Paket Businesslogik (kann explizit getestet
werden), ein Paket Darstellungslogik (kann explizit getestet und
angepasst werden, inklusive Layoutentscheidungen), +
Datenlogik (Model, Backend, Filesystem, whatever).

Quote

Sowas in der art ist schlecht.

Könntest du bitte *endlich* aufhören deine "Das ist so und
Schnauze!"-Nullargumente gebetsmühlenhaft zu wiederholen?
Das spricht nicht für dich. Aber ich *erkläre* es dir gerne
nochmal, ich möchte ja nicht, dass du etwas an Wissen
verpasst:

Eingebettete Logik ist *NICHT PER SE* schlecht. Es kommt auf
die Logik selbst an, ob eine Trennung erfolgt, oder nicht. Wenn
du nur die Positionen trennst, aber die Logiken mischt, ist das
um keinen Deut besser.

Quote

Entweder man macht HTML, oder PHP code, aber sollte nicht beides Mixen

Genau. Deswegen gibt es Smarty, das die ViewLOGIK auslagert.

Btw, nicht dass du mit deiner großkotzigen Art mal irgendwann
an die Wand fährst: <% %> geht auch bei PHP, sowie einigen
Perl Template Arten. Bei TT ist es frei definierbar, welchen
Begrenzungen man wählt. Deswegen war es eine Nullaussage.

Wobei, eigentlich war es diesmal *WIEDER* eine Nullaussage. Du
hast ja wieder nur dümpelich wiederholt, dass es so schlecht
sein, ohne Begründung. Was aber kein Wunder ist, oben schrieb
ich ja, warum du da nicht ausreichend differenzierst. Ich nehme
an, du betest einfach irgendwelche ideologischen Axiome
herunter, die dir irgendwann mal jemand gesagt hat.

Quote

und wer sowas schreibt sollte sich echt schämen.

Eigentlich solltest du dich schämen, dass du zwar haufenweise
Zeichen verschleuderst, aber keinen Inhalt einbringst. Aber
irgendwie hab ich das Gefühl, dass du das leider anders siehst.

Quote

Und wiedermal ein Beispiel für deine Wortverdreherei..
habe ich jemals von einem Webdesigner geredet der "kein HTML" kann?

Ach? Die verwenden dann Frontpage als Hobby? Ich lache noch
mehr :D

Quote

Und wie das heraussticht, ausserdem wird es geparst.

Aha. Ein

<a href="LINK">LINK_TEXT</a>

sticht mehr heraus als

<a href="[% link %]">[% link_text %]</a>

? Wobei man da wohl einen Generator hätte. In Catalyst zB [%
c.uri_for(...) %]. Das wäre die Hölle an Wartbarkeit wenn ich die
Links alle im Perlcode ändern müsste, weil ein Kunde an einer
Ecke was anders haben möchte...

Bzgl. wird geparst: Dann zeig mir dochmal wie dein Befehlssatz
aussieht. Wenn du schon das ganze Teil strukturell
durcharbeitest, machst du auch nicht so viel weniger als TT.

Wenn du ernsthaft nur TMPL_ irgendwas reinschreibst, nehme
ich an, dein "Parsen" ist ein Suchen&Ersetzen?

Quote

2. parsing ist schneller, da der ganze rest wegfällt(if, usw.).

Bist du sicher, dass du "parsed" und nicht nur den Begriff falsch
verstehst aber verwendest, weil er cool klingt? Wär ja nicht das
erste Mal.

Quote

FP zerstört code auch noch in der "aktuellsten" version...
Wenn man aber damit umgehen kann und nicht irgend einen mist markiert gehts.

Aha. Ich seh schon, das ist sicher *viel* besser als sparsames,
sauberes HTML selbst zu schreiben.

Quote

und ich finde, ihr motzt euch hier echt zu sehr an.

Find' ich nicht :D


p