Quote

Sorry das ist mir zu doof

Und mir ist es zu doof, dass du ständig nur deine Phrasen
wiederholst, anstatt sie durch Untermauerung in Argumente zu
wandeln.

Quote

Zudem waren es nur vorschläge und Ideen und kein
"Es muss so gelöst werden"

Dann solltest du *dringend* an deinen Formulierungen arbeiten:

Quote

If ist schlecht, weil die Programmierlogik klar in den Code gehört.
...
Daher sollte ein gutes template sehr wenige "funktionen" besitzen
...
"if" ist gehört nicht da ganz klar nicht rein
...
den rest sollte man den richtigen Programmiersprachen überlassen...
...
Wer so entwickelt soll sich schämen.
...
Ausserdem verleitet ein solches system zur schlechten entwicklung.
...
IF = Programmierlogik. hat "Layout" nichts verloren.
...
wieso also alles doppelt machen, umständlicher und langsamer?
...

Quote

Im selben Beitrag habe ich geschrieben das man die methode ja noch selber verfeinern muss

Ja, die Widersprüche in deinen Postings sind mir auch
aufgefallen.

Quote

Leider braucht ein Entwickler, auch etwas Fantasie, Kreativität und er muss LEEEESEN können... ach ja.. und "verstehen" . Eigenschaften die Dir ja fehlen.

Ganz und garnicht. Aber nachdem du ja jetzt auf den
Ad-hominem Zug aufgesprungen bist, stört dich meine
polemische Art ja sicherlich nicht mehr.

Aber wieder gab's keine ausführlichen Antworten. Wenn man das
zu der Tatsache dazurechnet, dass du versuchst Leuten Begriffe
zu erklären, die du nicht verstehst, fragt man sich wem hier
welche Eigenschaften fehlen...

Quote

Zeig mal selber Code her

Siehe TT, DBIC und das Catalyst-Projekt. Die APIs sind ja recht
aussagekräftig, dann weisst du, wie meine Scripte aussehen.

Ich finde es übrigens hübsch, dass du inzwischen übergegangen
bist, *nur* mehr direkt anzugreifen. Erwarte, dass ich dir das
entgegenhalte, wenn du *mir* das das nächste Mal vorwirfst.

Quote

...Niveauhaltende Beleidigungen gesnippt...

Quote

Ist die BL aussehalb braucht man sich nicht um die
programmiertechnischen Eigenheiten zu kümmern. bzw. man kann
den "Ablauf" (Was erscheint wann, nach welchem klick.)

Aha. Und wie implementierst du das? Telepathisch?

Es ist egal, ob du deine Logik in Perlcode oder in TT
Anweisungen hast, du wirst sie immer warten müssen. Andere
auch. Dafür wurde eben ein "flaches" datenzentriertes Interface
geschaffen. Und ob du <img src=""> im Perl stehen hast, ob
du Content per Search&Replace ersetzt oder in einer extra Perl
Datei HTML Dateien zusammenstöpselst ist egal.

*Deine Viewlogik ist damit im Quellcode!*

Das ist per se ja nichts Schlimmes, aber zu sagen das wäre
besser als ein Templatesystem ist ja fast schon fahrlässig.

Quote

Aber für die, welche nicht so schnell sind erkläre ich WARUM....

Mein lieber kleiner Freund. Falls du es noch immer nicht
geschnallt hast: Ich mache das (wie die meisten hier) beruflich.
Du musst mir nichts "erklären," ich wollte eine *Begründung*. Ist
dir der Unterschied zwischen diesen beiden klar? Darauf hätte ich
hier jetzt gerne eine Antwort!

Quote

also im Skript sofern man das Hauptprogramm als BL sieht

Du hast mir übrigens Businesslogik & Co. *noch immer nicht*
wirklich definiert. Ich darf dich zitieren:

Quote

LEEEESEN können... ach ja.. und "verstehen"

Quote

Schau sowas ist Katastrophen-Code:

Ich fasse es nicht.. So schwer kann es doch nicht sein?!
*BEGRÜNDE ES*. Eine Behauptung ist ungefähr soviel Wert wie
das, was mein imaginärer Hund beim Gassigehen verliert.

Und nein, ich sehe nichts schlechtes an <%=var %>. Und was
<%=response.write %> tut, weiss ich nicht. Ich nehme an, es
schreibt den Inhalt der Datei. Warum findest du das schlecht?
Weil es ASP steht? Weil du es mal wo gelesen hast? Ansonsten
wundert es mich, dass du *ABSOLUT KEINE* Begründungen für
deine Aussagen liefern kannst. Dafür wiederholst du sie aber
brav in jedem Beitrag.

Eine Trennung von View/Businness/Daten etc. ist dringend
anzuraten, klar. Ob das passiert, sieht man bei <% xyz %>
allerdings nicht. Wenn die Businesslogik im Template stehen
würde, wäre das schlecht. Wenn die Businesslogik Daten in zB
einem Stash bereitstellt, den der View (bzw. das Template)
verwenden um die HTML Seite(n) zu renden, und diese dann in
einen globalen Wrapper mit <% response.write(content) %> oder
TT's [% content %] eingebunden werden, sehe ich das als nicht
schlecht an, ganz im Gegenteil. Immer noch besser als
hardgecodetes HTML oder Templatenamen im Flow. Aber ich,
sowas tust du nicht, du verwendest es nur als Beispiel...

Ich glaube langsam eigentlich, du hast gar keine Ahnung
*warum* du in die Richtung diskutierst. Ansonsten hättest du
doch eine einzige Begründung liefern können.

Quote

Sachen wie "<TMPL NAME>" im HTML = Nicht Konform.

Und? '<img src="foo.jpg" ... />' ist auch kein gültiges HTML
Dokument. Oder bist du jetzt gegen deine eigene Praxis, das
HTML aufzusplitten? Wichtig ist das, was am Ende raus kommt.
Und das ist dann bei Template Engines genauso valide wie ohne.
Es hat überhaupt nichts damit zu tun. Also wieder ein
Nullargument.

Quote

Nun gibts aber das Problem, das man HTML-Kommentar in einem WYSIWYG-Editor nicht wie "text" bearbeiten kann.
also zeitverlust.

Deswegen schreibe ich HTML gleich von Hand. Tables, Formulare
etc. werden schon per (Template-)Modul generiert. Das
bedeutet sogar Zeitgewinn, wegen der Wiederverwendbarkeit.
Also noch ein Nullargument.

Quote

Was wäre die Lösung? Folgendes: "TMPL_NAME" das kann bearbeitet werden, um man sieht welche Variable wo wie aussieht.

Gefällt mir nicht. Sticht nicht heraus, wird nicht geparst und
kann daher keine Tippfehler finden.

Ich glaube, was du eigentlich suchst ist etwas wie
http://search.cpan.org/~TBONE/HTML-Seamstress/lib/HTML/Seamstress.pod

Quote

Mach Dich nicht noch lächerlicher!

Tue ich nicht. Was sich Designer nennt und kein HTML kann,
lache ich aus.

Quote

Was ist wohl schneller, übersichtlicher, einfacher?

Plain HTML. Weil man die Kontrolle über Semantik, Effizienz, etc.
hat. Weil man gleich für alle Browser konform arbeiten kann, usw. usf.

Quote

Du bist bestimmt einer von denen die z. B. über Frontpage schimpfen. "er zerstört den code" *lach*

Seit irgendeiner pre-2000er Version tut es das afaik nicht mehr.
Semantisch sauberen und effizienten Code produziert es
trotzdem nicht. Da fand ich NVU angenehmer. Keine Sorge, ich
hab sowas schon gesehen und verwendet. Allerdings für HTML
Dokumente, nicht für Applikationsinterfaces.

Quote

Dann nimm doch gleich z. B. Notepad für deine Perl-Skripts.... Warum? "Ganz einfach ein besserer Editor(Farbig usw.) ... den braucht man nicht wenn mans kann..." *lach*

Der Vergleich hinkt noch um Einiges mehr als der Rest deiner
Meinung :)

Quote

Endlich mal wieder einen vernünftigen Beitrag!
Es geschehen noch Wunder!

So vernünftig finde ich deinen Beitrag nicht. Gut, er enthält
keine falschen Aussagen, Beleidigungen, Unterstellungen oder
Ausweichtaktiken. Allerdings demonstrierst du, dass bei deiner
Methode die Darstellungslogik fix in der Anwendung ist, und du
sie per Include (warum nicht gleich etwas nicht-perliges?)
konfigurierst. Wenn sich die Logik selbst ändert, musst du wieder
ran. Insofern haben wir also jetzt zwei Fronten:

Die einen haben eine flache, zielgerichtete Logik im Template.
Mit IFs, INCLUDEs, LOOPs, FORs, MACROs und so weiter und so
fort. Eben alles, was sich um das Interface kümmert.

Die anderen bevorzugen Perl und haben einen extra Layer (mit
Glück) in dem sie das machen.

Das ist eigentlich kein Unterschied, außer dass man die
Templates eventuell nicht im WYSIWYG Editor bearbeiten kann.

Ist das wirklich dein einziges Argument? Wenn nein, bringe
welche ein.