[quote=master,12.05.2006, 16:29]Sowas in der art ist schlecht.. Entweder man macht HTML, oder PHP code, aber sollte nicht beides Mixen... gleiches gilt für alle ähnlichen Skript-/ Programmiersprachen.

Es gibt viele die so entwicklen.. (leider) und wer sowas schreibt sollte sich echt schämen.[/quote]
genau das ist es, was mich stört - dein anspruch, dass du hier der lehrer
bist und die anderen sich zu schämen haben.
argumente der art, dass es einige leute gibt, die eine andere meinung
haben als du und das auch äußern, fegst du mit einem verächtlichen
"leider gibt es viele, die so denken" (sinngemäß) weg.

ich habe immer noch kein schönes beispiel für deine methode von dir
gesehen; das liegt vermutlich auch daran, dass die Template-Module, die
strat, P und ich (etc.) erwähnten, auf CPAN liegen und es massig
anwendungen gibt.
deinen "templating"- code kennst nur du, und das einzige, was du hier
postest, sind funktionsaufrufe, die ja ach so einfach aussehen, aber
was die funktionen machen und wie es dann im zusammenhang aussieht,
schreibst du nicht.

das ist das, was mir fehlt, und wenn du mal sowas posten möchtest,
können wir alle auch konkreter diskutieren.
ansonsten ist eine diskussion über templating immer eine heikle
sache, und ich finde, ihr motzt euch hier echt zu sehr an.\n\n

<!--EDIT|pq|1147447473-->

@pq: ich motze nicht, ich parliere ;-)

aber das mit dem code halte ich fuer eine gute idee; vielleicht verstehe ich dann, warum master der meinung ist, dass alle IFs in Templates an der falschen stelle sind.

Bei mir sieht ein template haeufig folgendermaszen aus:

und standardstart koennte folgendermaszen aussehen:



sowas hat den vorteil, dass ich das template in mehrere kleinere teile aufteilen kann aber ich habe halt ein komplettes template pro seite, und die meisten includierten templates werden von mehreren seiten gemeinsam verwendet.

Wenn ich master richtig verstehe, macht er das fast genauso, nur verwendet er anstelle meines haupttemplates ein perl-programm und darin ueberhaupt kein html, sondern included alles, wodurch meist eine menge kleiner templates entstehen.

Stimmt meine Vermutung so?\n\n

<!--EDIT|Strat|1147449586-->

@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

Und wenn wir schon bei Templatebeispielen vorzeigen sind :)

site_border.html:


wrap.html: (Als Default Wrapper eingestellt)


Der content in wrap.html ist das Haupttemplate. Die sehen halt
grossteils anders aus. Wenn das Template zB keine Navigation
möchte, kann es einfach

[% SET c.stash.wrap_site = 0 %]

oder ähnliches tun.


p

@strat: mit motzen meinte ich eher master und P =)

zu deinen templates: so mache ich das bei mir auch, wobei ich immer
denke, umgekehrt hätte auch was, also ein einziges template:

das hat den vorteil, dass du immer öffnende und schließende
abschnitte in einem template hast, also <html>...<body>...</body></html>
da hat man wohl einen besseren überblick, in welcher verschachtelungstiefe
man sich befindet.\n\n

<!--EDIT|pq|1147457161-->

@pq: zu umgekehrt: stimmt, sowas wuerde gerade bei HTC oft Sinn machen, weil man da ja include variable schreiben kann. Wenn man was neues verwendet, sollte man sich vielleicht doch mal ueberlegen, ob man damit nicht vielleicht auch noch andere sachen effizienter machen kann und nicht einfach weitermachen wie gewohnt... denn dass ich bei HTML::Template den von mir oben angegebenen Weg gehen musste, fand ich mal nicht so toll...

@Strat

Quote

warum ist das schlecht? Was willst du uns mit dem Codebeispiel sagen?

Es ist schlecht, weil HTML-code im PHP-Skript steht.
HTML hat dort nicht zu suchen (wegen der Trennung) mit HTML stellst du ja was dar. ein template wäre besser..



@P
Vielleicht hast du ja wiedermal überlesen, wäre ja nichts neues, das ich wieder sachlicher wurde.

Werd glücklich wenn ich auf deinen dummen Beitrag nicht mehr wirklich eingehe. Sachlich können wir weiter reden, anders nicht. Punkt.

Es hat keinen nämlich Sinn, deine beiträge werden immer länger, deine Beleidigungen immer grösser. (Parsing, Troll, usw.)

Pausenlos nimmst du meine Beiträge - spitzfindig - auseinander...

Du willst einen genauen CODE sehen wie meine Funktion funktioniert???? vergiss es... denkst du etwa ich mach hier kindergarten? und erkläre alles von A-Z???? DIR????
Code:

Eigentlich habe ich erwartet, das du dir den rest denken, oder selbst entwickeln kannst... aber das hier ist nunmal kein Perl-Grundkurs.


Ende der Diskusion...

@strat

Quote

Wenn ich master richtig verstehe, macht er das fast genauso, nur verwendet er anstelle meines haupttemplates ein perl-programm und darin ueberhaupt kein html, sondern included alles, wodurch meist eine menge kleiner templates entstehen.

Stimmt meine Vermutung so?

Korrrekt... (Nur Perl in Perl, rest draussen.)

Die kleineren Templates werden dann sinngemäss abgelegt.
so das alleine durch Namensgebung und Pfad und Dateiname
klar ist worum es sich handelt.

z. B. (so in der art)
main.html (haupt template)
gallery.html

@PQ

Quote

das ist das, was mir fehlt, und wenn du mal sowas posten möchtest, können wir alle auch konkreter diskutieren.

Eigentlich möchte ihr gar nicht, alles bis ins Detail aufzeigen.

Quote

"sowas ist schlecht"

genau das ist es, was mich stört - dein anspruch, dass du hier der lehrer
bist und die anderen sich zu schämen haben.
argumente der art, dass es einige leute gibt, die eine andere meinung
haben als du und das auch äußern, fegst du mit einem verächtlichen
"leider gibt es viele, die so denken" (sinngemäß) weg.

Nun es ist eben schlecht, HTML-Code direkt ins Perl/PHP Skript zu schreiben. Da sollte man wenigstens templates nutzen.

Warum es schlecht ist sowas wie ich den PHP-Code gezeigt habe zu machen ist doch wirklich klar oder?

Begründungen kannst du weiter oben lesen, als antwort auf den Thema-Eröffner, der machts nämlich falsch.

Schreibt man ALLES ins Skript dann hat man KEINE trennung.
Also Probleme bei LAyout-änderungen usw.

Und Layout-änderungen wünschen Kunden leider oft.. meist wenn alles schon steht. z.b. als Argument...

Darum beharre ich drauf die Gestaltung nicht in den Code zu nehmen. PHP ermöglicht hier durch seine Syntax jedoch genau das gegenteil zu tun. und viele mach das dann so, weil es "Schneller" erscheint.

[quote=master,14.05.2006, 11:49]
Eigentlich habe ich erwartet, das du dir den rest denken, oder selbst entwickeln kannst... aber das hier ist nunmal kein Perl-Grundkurs.[/quote]
Kann bitte jemand den Thread schliessen! Die Diskussion erfolgt ergebnisfrei, wenn mit solch aussagekräftigen Beispielen agiert wird. Hier kann auch niemand was lernen, außer wie sich Leute öffentlich ins Aus stellen.