Welche Template-Technik für kleinen Website mit statischem HTML? (Fragen zu Perl-Modulen)

[thread]18165[/thread]

Welche Template-Technik für kleinen Website mit statischem HTML?

Tags: perl5 HTML template Ähnliche Threads

Leser: 25

Articles: hide open all | hide show old branches

+28 replies
payx

2013-02-23 10:12

User since
2006-05-04
564 Artikel
BenutzerIn

Hallo,

ich will einen kleinen Website mit ein paar Handvoll statischen HTML-Seiten relaunchen. Dynamisches HTML ist nicht erlaubt und auch nicht vonnöten.

Es handelt sich um die Präsentation eines Vereins mit gut 80 HTML-Seiten; alle paar Monate kommen 1-2 Seiten dazu, und etwa ebenso oft muss an vorhandenen Inhalten etwas geändert werden. HTML, CSS und Design sollten überarbeitet werden. Header und Footer nicht mehr per Copy and Paste verteilt werden usw.

Nun würde ich gern Form und Inhalt sauber trennen und auf jeden Fall Perl benutzen, um die statischen Seiten zu erzeugen.

Mit den gängigen Template-Modulen habe ich noch nie etwas gemacht, also ist das jetzt eine schöne Gelegenheit, da mal einzusteigen. Meine Frage: Was würdet Ihr mir empfehlen?

StringsTemplateEngines habe ich gelesen und auch das dort verlinkte sehr gut geschriebene Tutorial bei mod_perl. (Der Autor ist hier seinem Anspruch – "I've tried to present a balanced appraisal of the features of various systems" – allerdings allzu gerecht geworden, sodass sich mir nicht erschlossen hat, welches sein Favorit ist.)

Die naheliegendsten Kandidaten sind wohl Template::Toolkit (TT), Text::Template und HTML::Template (oder HTML::Template::Compiled -?).

Caching, Performance usw. spielen für den genannten Einsatzzweck (naturgemäß) keine große Rolle, eher Mächtigkeit und Bedienbarkeit.

Meine bisherigen Überlegungen gehen in Richtung TT (es wird für einen solchen Einsatzzweck auch in msg #163001 empfohlen), weil es das mächtigste und vielseitigste zu sein scheint, vor allem, wenn man künftig auch andere als HTML-Templates verarbeiten will.

Bequem scheint bei TT die Möglichkeit zu sein INTERPOLATE => 1 zu setzen und so direkt Perl-Variablen ins HTML zu schreiben. Aber das widerspricht wahrscheinlich tendenziell dem Anspruch der Trennung von Form und Inhalt, oder wie seht Ihr das?

Für Tipps und Denkanstöße, bevor ich vielleicht das falsche Pferd erklimme, bin ich dankbar!

Viele Grüße
payx
- +3 replies
- jan
  
  2013-02-23 10:40
  
  User since
  2003-08-04
  2536 Artikel
  ModeratorIn
  
  Ich mag persönlich auch das TT am liebsten. Aber: wieso willst Du die Dateien eigentlich selbst erzeugen? Auch das nimmt TT dir ab, wenn Du willst, da kommen entsprechende Scripte mit bei der Installation.
  - +2 replies
  - payx
    
    2013-02-23 11:29
    
    User since
    2006-05-04
    564 Artikel
    BenutzerIn
    
    Hallo jan,
    
    danke für Deine Antwort. Du meinst Template::Tools::ttree, nehme ich an?
    
    Ja, das hatte ich gesehen – und auch damit gemeint, dass ich die Dateien mit Perl (bzw. einem Template-Modul) erzeugen will. Wenn ich es recht überblicke, bieten alle genannten Template-Techniken prinzipiell eine solche Möglichkeit an. Wie gut diese Möglichkeiten funktionieren usw., weiß ich aber nicht, daher dieser Thread in der Hoffnung auf ein paar Erfahrungsberichte ...
    
    Hast Du solche Projekte wie das von mir beschriebene schon mit TT umgesetzt?
    
    Viele Grüße
    payx
    - jan
      
      2013-02-23 11:52
      
      User since
      2003-08-04
      2536 Artikel
      ModeratorIn
      
      Genau das meinte ich, ja. Ich hab damit aber nur mal rumgespielt als ich mit TT angefangen habe, ich habe nie wirklich damit gearbeitet.
- +2 replies
- GwenDragon
  
  2013-02-23 12:14
  
  User since
  2005-01-17
  14532 Artikel
  Admin1
  
  Solange du das pflegst, kannst du Perl einbauen, aber wenn es jemand anders macht, kanns problematisch werden.
  die Drachin, Gwendolyn
  
  Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
  - payx
    
    2013-02-23 12:34
    
    User since
    2006-05-04
    564 Artikel
    BenutzerIn
    
    Hallo GwenDragon,
    
    zum Verständnis: Du beziehst Dich auf die TT-Option INTERPOLATE => 1, oder?
    
    Vorläufig werde wohl nur ich die Seiten pflegen, aber die Erde dreht sich ja weiter.
    
    Und vermutlich stimmt: Wenn man schon Form und Inhalt trennen will, dann sollte es richtig gemacht werden, also wenn TT, dann nur mit der TT-eigenen Mini-Language.
    
    (Oder lieber doch nicht TT?)
    
    Grüße
    payx
- +2 replies
- rosti
  
  2013-02-23 13:00
  
  User since
  2011-03-19
  3193 Artikel
  BenutzerIn
  
  hi,
  
  INTERPOLATE ist zwar verlockend, löst jedoch die Aufgabenstellung "Trennung Layout vom Programmcode" überhaupt nicht.
  
  Ich habe ein halbes Jahr mit dem Template::Toolkit (Dachs, TT) gearbeitet und kann es empfehlen. In den Templates operierst Du nur noch mit den vom Controler (Model Class) bereitgestellten Referenzen auf Datenstrukturen, das sind Strings, Arrays und Hashes.
  
  Z.Z. entwickle ich privat mit PHP und trende da zu Twig als Template-Engine, Twig ist dem Dachs sehr ähnlich. Selbst mit PHP als Native Template-Engine zu arbeiten, macht das Programmieren mit PHP zu einer erträglichen Sache ;)
  
  http://rolfrost.de/blog.html?d=20130222
  - payx
    
    2013-02-23 13:28
    
    User since
    2006-05-04
    564 Artikel
    BenutzerIn
    
    Hallo rosti,
    
    danke für Deinen Beitrag. INTERPOLATE wäre ein Irrweg, das habe ich jetzt verstanden.
    
    Zu Twig habe ich in der Perl-Welt erstmal nur XML::Twig gefunden. Das ist wohl nicht das, was Du meinst. (Umstieg auf PHP kommt für mich derzeit nicht in Betracht.)
    
    Wenn jetzt nicht bald jemand schreibt "Finger weg, nimm lieber ...", dann werde ich wohl in TT einsteigen.
    
    Viele Grüße
    payx
- +6 replies
- pq
  
  2013-02-23 13:33
  
  User since
  2003-08-04
  12208 Artikel
  Admin1
  
  naturgemäss würde ich HTML::Template::Compiled empfehlen ;-)
  TT mag ich wegen der eigenen sprache nicht so sehr. ausserdem kann es von haus aus kein default-escape (was bei statischen seiten aber nicht so wichtig ist).
  hast du dir Text::Xslate angesehen? die seite im wiki ist auch schon etwas veraltet, da steht es noch nicht drin.
  Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
  lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
  - +5 replies
  - payx
    
    2013-02-24 11:44
    User since
    2006-05-04
    564 Artikel
    BenutzerIn
    
    Hallo pq,
    
    vielen Dank für Deinen Beitrag.
    
    Was wäre denn der Vorteil von HTML::Template::Compiled gegenüber Template::Toolkit – für meinen Einsatzzweck?
    
    Ich fasse nochmals zusammen (bzw. ergänze und präzisiere):
    
    Statischer HTML-Output
    Saubere Model-View-Separation
    Vielseitigkeit, Möglichkeit auch andere als HTML-Templates zu verarbeiten
    Benutzerfreundlichkeit, Dokumentation
    
    Danke auch für den Hinweis auf Text::Xslate. Das kannte ich noch nicht. Auch in dem genannten Tutorial ist es nicht erwähnt, obwohl es Aktualität vorschützt (erst neulich last modified) und das Modul schon fast seit drei Jahren existiert. Hört sich interessant an, wird auch offenbar eifrig gepflegt. Hat jemand Erfahrungen damit?
    
    Wie bei HTC wird als Hauptvorteil die gute (angeblich noch bessere) Performance angepriesen, die für mich mit meinen kaum 100 statischen HTML-Seiten ja praktisch keine Rolle spielt. (Ich mutmaße, dass alle in Frage kommenden Template-Techniken mit der Erzeugung der Dateien schneller sind, als ich in das Output-Verzeichnis navigieren kann.)
    
    Trotzdem wird meine Entscheidung dadurch nicht einfacher.
    
    Was nützlich wäre, wäre so eine Entscheidungsmatrix, wo alle Features direkt verglichen werden können (wie bei der Stiftung Warentest oder wie in dieser Urfassung des mod_perl-Template-Tutorials.) Leider habe ich nichts aktuelles gefunden.
    
    Frage: Wäre es nicht eine Idee, so eine Matrix im Wiki aufzubauen? Dann könnten wir unser Wissen darin strukturiert zusammentragen.
    
    Viele Grüße
    payx
    - +4 replies
    - pq
      
      2013-02-24 12:43
      
      User since
      2003-08-04
      12208 Artikel
      Admin1
      
      das tutorial auf apache.org ist uralt. leider sehe ich nirgendwo den erstellungszeitpunkt, noch, was am 11. Februar 2013 geändert wurde =(
      
      dass performance hier keine rolle spielt, ist klar.
      gegenüber H::T hat H::T:C auch noch den vorteil von mehr funktionen, tagstyles, dot-notation etc. allerdings bei gleichbleibender basis-syntax, und das finde ich gegenüber TT gut. tag-delimiter tag-name attribut=value tag-delimiter. das ist immer gleich. TT hat eine eigene sprache. blöd finde ich, dass jedes tag mit [% END %] beendet wird, dass man also nicht sieht, ob das öffnende tag ein if oder eine schleife oder sonstwas ist.
      
      ist also geschmackssache.
      Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
      lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
      - +3 replies
      - payx
        
        2013-02-25 21:16
        
        User since
        2006-05-04
        564 Artikel
        BenutzerIn
        
        Hallo pq,
        
        das Tutorial ist mindestens vom August 21, 2001 12:00 AM (siehe Perrin Harkins' Blog bei perl.com). Also wirklich nicht mehr ganz taufrisch.
        
        Also, ich bin immer noch nicht so recht entschieden. Vor allem mit Text::Xslate hast Du mich schön ratlos gemacht. Was ist mit meiner Idee einer Vergleichs-/Entscheidungsmatrix im Wiki?
        
        Auf meine Frage, was der Vorteil von HTML::Template::Compiled gegenüber Template::Toolkit (für meinen Einsatzzweck) ist, hast Du mir nicht geantwortet, Du hast es nur mit HTML::Template verglichen.
        
        [% END %] ohne Wiederholung des einleitenden Befehls ist wirklich nicht so schick. Es erinnert einen daran, dass man nicht zu viel Logik in so ein Template packen sollte, d.h. komplexe Business-Logik gehört eigentlich ins Backend. Und dann sollten Ketten von fünf-sechs [% END %]-Elementen hintereinander eher nicht vorkommen.
        
        Ich hoffe weiterhin auf das schlagende Argument für eine der Techniken.
        
        Viele Grüße
        payx
        
        +2 replies
        
        pq
        
        2013-02-26 13:16
        
        User since
        2003-08-04
        12208 Artikel
        Admin1
        
        2013-02-25T20:16:27 payx
        Also, ich bin immer noch nicht so recht entschieden. Vor allem mit Text::Xslate hast Du mich schön ratlos gemacht. Was ist mit meiner Idee einer Vergleichs-/Entscheidungsmatrix im Wiki?
        
        gerne =)
        
        Quote
        Auf meine Frage, was der Vorteil von HTML::Template::Compiled gegenüber Template::Toolkit (für meinen Einsatzzweck) ist, hast Du mir nicht geantwortet, Du hast es nur mit HTML::Template verglichen.
        nein, hab ich nicht nur.
        Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
        lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
        
        payx
        
        2013-02-28 21:09
        
        User since
        2006-05-04
        564 Artikel
        BenutzerIn
        
        Hallo pq,
        
        2013-02-26T12:16:40 pq
        2013-02-25T20:16:27 payx
        Also, ich bin immer noch nicht so recht entschieden. Vor allem mit Text::Xslate hast Du mich schön ratlos gemacht. Was ist mit meiner Idee einer Vergleichs-/Entscheidungsmatrix im Wiki?
        
        gerne =)
        Dazu habe ich Dir gerade eine PM geschickt ...
        
        Quote
        Quote
        Auf meine Frage, was der Vorteil von HTML::Template::Compiled gegenüber Template::Toolkit (für meinen Einsatzzweck) ist, hast Du mir nicht geantwortet, Du hast es nur mit HTML::Template verglichen.
        nein, hab ich nicht nur.
        Ja, stimmt, sorry.
        
        Du schriebst:
        
        Quote
        ... H::T:C auch noch den vorteil von mehr funktionen, tagstyles, dot-notation etc. allerdings bei gleichbleibender basis-syntax, und das finde ich gegenüber TT gut. tag-delimiter tag-name attribut=value tag-delimiter. das ist immer gleich. TT hat eine eigene sprache. blöd finde ich, dass jedes tag mit [% END %] beendet wird, dass man also nicht sieht, ob das öffnende tag ein if oder eine schleife oder sonstwas ist.
        
        Das Mehr an Funktionen bezieht sich noch auf HT, wenn ich es recht verstanden habe. Was ist an tagstyles gut? Bzw. was ist damit gemeint? CSS steht mir doch immer zu Gebote, wenn ich etwas mit HTML mache, und Style gehört ja wohl eindeutig in die View-Schicht, also schon ins Template aber eben in die HTML-Bestandteile, nicht in die dynamischen. Vielleicht fällt es mir im Moment aber auch nur zu schwer, mir ein Beispiel vorzustellen.
        
        Dot-Notation (für den Zugriff auf Datenstrukturen) gibt es bei TT auch.
        
        Die gleichbleibende (wenn auch proprietäre, dafür aber recht einfache) Syntax scheint mir bei TT ebenfalls gegeben zu sein.
        
        Ich sehe schon, ich werde ein bis zwei Lösungen ausprobieren müssen.
        
        Viele Grüße
        payx
- +7 replies
- GwenDragon
  
  2013-02-23 14:53
  
  User since
  2005-01-17
  14532 Artikel
  Admin1
  
  Wer bei TT auf die schrägen Text-Elemente [% %] statt X(HT)ML steht, mag ja perlig sein, vom Standpunkt des Webdesigns mit diversen Webdesigneditoren aber ein Hemmnis. Wenn sollte man da den TAG_STYLE auf ASP oder PHP ändern.
  die Drachin, Gwendolyn
  
  Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
  - +6 replies
  - jan
    
    2013-02-23 17:32
    
    User since
    2003-08-04
    2536 Artikel
    ModeratorIn
    
    Genau das finde ich immer ungut, weil man so im Browser ohne Template-Engine gar nichts sehen kann, weil die Platzhalter als Kaputte Tags erkannt werden.
    - rosti
      
      2013-02-23 23:10
      
      User since
      2011-03-19
      3193 Artikel
      BenutzerIn
      
      Interessant wirds auch, wenn über die Templates ein Indexer laufen soll, etwa für eine eigene Suchmaschine.
    - +4 replies
    - GwenDragon
      
      2013-02-24 10:26
      
      User since
      2005-01-17
      14532 Artikel
      Admin1
      
      2013-02-23T16:32:59 jan
      (...)weil man so im Browser ohne Template-Engine gar nichts sehen kann, weil die Platzhalter als Kaputte Tags erkannt werden.
      Du meinst, wenn bei TT der TAG_STYLE nicht auf ASP oder PHP gestellt ist? Oder worauf beziehst du dich?
      die Drachin, Gwendolyn
      
      Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
      - +3 replies
      - jan
        
        2013-02-24 10:53
        
        User since
        2003-08-04
        2536 Artikel
        ModeratorIn
        
        Ja, genau.
        Wenn Designer ohne volle Entwicklungsumgebung entwickeln und die Templates einfach als HTML nutzen, sehen sie nix im Browser, wenn es
        
        Code: (dl )
        
        <div><? varname ?></div>
        
        ist.
        bei
        
        Code: (dl )
        
        <div>[% varname %]</div>
        
        sehen sie [% varname %] und wissen, was wo sitzt.
        
        +2 replies
        
        GwenDragon
        
        2013-02-24 11:05
        
        User since
        2005-01-17
        14532 Artikel
        Admin1
        
        OK, für Designer ist das [% %] sinnvoller, die können oft kein X(HT)ML lesen.
        die Drachin, Gwendolyn
        
        Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
        
        payx
        
        2013-02-24 11:46
        
        User since
        2006-05-04
        564 Artikel
        BenutzerIn
        
        Hallo GwenDragon und jan,
        
        ich denke auch, dass ich die [% TT %]-Schreibweise gut finden werde, wenn ich mich denn für TT entscheide.
        
        Vorteil: Sie ist über alle Arten von zu produzierendem Output gleich und eben TT-spezifisch, wie die so markierten Konstrukte.
        
        Egal also, ob ich HTML, XML, SQL, odt-Dateien oder sonst etwas erzeugen will, immer werde ich diese gleichartigen Konstrukte haben, die sich in all diesen Umgebungen schön deutlich abheben und unverwechselbar sind.
        
        Und das Argument von jan zieht auch, dass die Template-Dateien (außer SQL natürlich) mit den Platzhaltern und Direktiven darin auch schon funktionieren und auf Design, Wohlgeformtheit usw. geprüft werden können.
        
        Danke für die Denkanstöße
        und viele Grüße
        payx
- +7 replies
- Muffi
  
  2013-02-23 23:06
  
  User since
  2012-07-18
  1465 Artikel
  BenutzerIn
  
  ich mag Text::Template::Simple ganz gern.
  1 + 1 = 10
  - +6 replies
  - payx
    
    2013-02-24 11:44
    User since
    2006-05-04
    564 Artikel
    BenutzerIn
    
    Hallo Muffi,
    
    vielen Dank für Deinen Beitrag. Text::Template::Simple kannte ich noch nicht. Ich habe es mir angesehen (nicht ausprobiert). Wirklich auf den ersten Blick bestechend simpel.
    
    Keine Mini-Language und also auch keine so ganz klare View-Model-Separation. Durch entsprechende Disziplin bei der Entwicklung kann man diese aber vielleicht trotzdem erreichen. (Ein Sicherheitsrisiko ist das bei statischen Seiten natürlich ohnedies nicht.)
    
    Was mich ein bisschen abschreckt, sind die vielen magischen Zeichen.
    
    <% %> Code Blocks
    <%= %> Self-printing Blocks
    <%! %> Escaped Delimiters
    <%+ %> Static Include Directives
    <%[*] %> Dynamic include directives
    <%# %> Comment Directives
    <%| %> Blocks with commands
    
    Das ist gut (wie gute Tastaturshortcuts), wenn man viel und fortgesetzt damit arbeitet, denke ich.
    
    Die etwas behäbiger formulierten Direktiven in TT werde ich aber voraussichtlich auch nach sechmonatiger Pause noch (wieder) mühelos verstehen.
    
    Welche von den vielen Features der anderen – nicht explizit simplen – Template-Engines mir hier zu welchem Zeitpunkt schmerzlich fehlen werden, fällt mir aus jetziger Sicht schwer abzuschätzen.
    
    Weitere Sorge: Das letzte Update ist fast ein Jahr her. Ein lahmendes Pferd?
    
    Trotz dieser Bedenken eine Alternative, die ich in Betracht ziehe.
    
    Viele Grüße
    payx
    
    Editiert von payx: überflüssige escapes entfernt
    Last edited: 2013-02-24 11:49:33 +0100 (CET)
    - Muffi
      
      2013-02-24 11:53
      
      User since
      2012-07-18
      1465 Artikel
      BenutzerIn
      
      Wenn dir die Blöcke zu viel sind reichen eigentlich die ersten 2.
      
      Ich mags halt, weil ich nicht irgendeine Spezialsyntax brauch.
      1 + 1 = 10
    - +4 replies
    - Muffi
      
      2013-02-25 08:14
      
      User since
      2012-07-18
      1465 Artikel
      BenutzerIn
      
      2013-02-24T10:44:59 payx
      Keine Mini-Language und also auch keine so ganz klare View-Model-Separation. Durch entsprechende Disziplin bei der Entwicklung kann man diese aber vielleicht trotzdem erreichen.
      
      Das ist jetzt nur meine persönliche Meinung und da gibts viele, die sehn das anders. Auch mit guten Gründen.
      
      Ich mag diese überstrikte Trennung/Einschränkung garnicht so gern. Und irgendwie hab ich das Gefühl ist es nicht so ganz der Gedanke von Perl alle Freiheiten offen zu lassen und du musst selbst entscheiden ob es grad Sinn macht.
      1 + 1 = 10
      - +3 replies
      - payx
        
        2013-02-25 21:30
        
        User since
        2006-05-04
        564 Artikel
        BenutzerIn
        
        Hallo Muffi,
        
        die Trennung von Form und Inhalt oder Logik und Präsentation oder Model und View ist nach meiner Erfahrung eigentlich schon fast immer richtig, zumindest immer dann, wenn es über eine Minimallösung hinausgeht, die über längere Zeit, zu verschiedenen Zwecken oder verschiedenen Nutzern (die die Lösung vielleicht modifizieren oder pflegen müssen) dienen soll. Bei Projekten, die als Schnell-schnell-Lösung gestartet sind und auf diese Trennung verzichtet haben, dann aber doch einigen Umfang angenommen haben (z.B. dynamische Generierung von SQL-Scripten aus komplexen Metadaten in einem Perlscript mit >2000 Zeilen), bin zumindest ich immer wieder an den Punkt gelangt, an dem ich feststellen musste, dass eine klare Schichtung besser gewesen wäre. (Sie nachträglich einzuziehen kommt einem kompletten Refactoring nahe, klar.)
        
        Wenn ich heute hier stehe und nach einem Template-Subsystem suche, dann tue ich das als in dieser Hinsicht Geläuterter.
        
        Aber zugegeben: Ich bin selbst gespannt, ob ich das nächste Mal, wenn in einem Projekt schnell eine Lösung gebraucht wird, um dies oder jenes aus dem oder jenem zu erzeugen, gleich Templates erstellen und sinnvoll Logik vom Inhalt trennen oder doch lieber ein straightforward-Script schreiben werde.
        
        Das kommt wohl darauf an, wie ich mit der am Ende dieses Threads gewählten Template-Technik zurecht komme.
        
        Danke für Deinen Input jedenfalls
        und viele Grüße
        payx
        
        rosti
        
        2013-02-26 08:33
        
        User since
        2011-03-19
        3193 Artikel
        BenutzerIn
        
        Einmal Template => Immer Template ;)
        Es gibt, außer dem Erstellen kompletter Webseiten noch mehr Einsatzmöglichkeiten für Templates, z.B. PDF oder Maildateien. Interessant wirds, wenn MIME Mails erstellt werden sollen, also Multipart, hierzu ist eine Template-Engine geradezu ideal, die Attachments über eine Schleife einzubauen.
        
        PS: Weitere Einsatzmöglichkeiten fand ich in Scripts, die auf der Kommandsozeile laufen, um diese Scripts mit dem Template zusammen so kompakt wie möglich zu gestalten, baute ich das Template in den __DATA__ Handler.
        Last edited: 2013-02-26 09:22:18 +0100 (CET)
        
        Muffi
        
        2013-02-26 08:56
        
        User since
        2012-07-18
        1465 Artikel
        BenutzerIn
        
        Quote
        die Trennung von Form und Inhalt oder Logik und Präsentation oder Model und View ist nach meiner Erfahrung eigentlich schon fast immer richtig
        
        Klar. Nur diese Trennung um jeden Preis ist mir irgendwie zu viel. Ich fühl mich von diesen limitierten Mini-view-pseudo-sprachen immer irgendwie eingeengt und behintert und dann wenn man mal wirklich froh wäre, dass mans ganz streng getrennt hat funktionierts in der Praxis eh nicht so wie erwartet.
        Beispiel (schon ein paar Jährchen her) Eine Seite für Desktop, Mobilebrowser und einfaches HTML4 zum Umwandeln nach pdf. Ursprünglich gabs nur Desktop, strikte Trennung war aber da.
        Meine Erwartung: Neue views schreiben und sonst nix.
        Praxis: klappt nicht. Man fuhrwerkt trotzdem über alle Bereiche im Code.
        
        Da nehm ich lieber 98,5% Trennung, fühl mich nicht dauernd eingeengt und im Falle des Falles ist es dann auch nicht merklich mehr Umbau.
        Allerdings muss man sich dann selbst ständig am Riemen reissen und diszipliniert arbeiten und das ist wohl der größte Nachteil.
        Ich hab in Templates schon handgeschriebenes SQL gesehn, weils halt einfach geht. Mit einem strikten Templatesystem geht so Blödsinn schon von vornherein nicht.
        
        [EDIT] Weils mir grad wieder einfällt: Ein Punkt, der mir z.B. regelmässig einen Strich durch meine schöne aufgeräumte Welt gemacht hat war Tagging [EDIT2]aufgeblasene Variante des counter-pixels[/EDIT2].
        Da mussten zig Daten aufbereitet und übergeben werden, die einfach nur wirr und view-abhängig waren.
        Da gibts 2 Möglichkeiten. Entweder man kapselt sich tot weils massenhaft aufbereitete Einzelwerte gibt, die nach view kombiniert und verändert werden. Mit der hab ich angefangen. Oder man blickt dann irgendwann garnicht mehr durch und klatscht den ganzen Taggingcode einfach in den view rein. Hässlich, aber man hat wenigstens mehr Überblick.
        Last edited: 2013-02-26 10:07:36 +0100 (CET)
        1 + 1 = 10

View all threads created 2013-02-23 10:12.