WebsiteBaker Support (2.8.x) > Diskussion über WB (closed)
Template Engine, Sinn und Unsinn.
cwsoft:
--- Quote ---@cw-soft: Wie bist du die Umstellung deiner Module angegangen
--- End quote ---
Na einfach Schritt für Schritt (sprich Datei für Datei) für alle Module: Postits, Anynews, AFE :-)
NorHei:
Jeder der Hier diskutierenden hat ein gewisses Maß an Programmiererfahrun g, Erfahrung mit HTML,CSS und meist auch verschiedenen TEs. Kein Wunder das da alles kein Problem ist.
Jetzt versucht euch mal in jemanden hineinzu versetzen der grade mal rudimentäre HTML Kenntnisse ala Selfhtml hat, Programmierung 0%, sprich ein Einsteiger. Aus eigener Erfahrung weiß ich das diese Leute mehr als glücklich sind wenn sie sich weder mit Verzweigungen noch mit includes oder Sowas rumschlagen müssen. Die freuen sich drüber wenn das HTML schön in HEAD LOOP und FOOTER zergliedert ist in Verbindung mit ner netten Infobox was die Grundsätzlichen Ersetzungen so Bieten... ENDE
Technisch sollte es doch gar kein Problem darstellen die 3 Boxen aus der DB zu fischenn aneinander zu hängen , noch das Loop Kommando einzufügen und dann durch die TE zu jagen.
Theoretisch würde das sogar bedeuten, das ein Profi einfach alles in den Head packen kann weil der leere Loop einfach nichts macht und der Einsteiger hätte strukturen die das verstehen drastisch vereinfachen.
Ich denk da So an meine ersten Erfahrungen mit einigen anderen CMS. Mann installiert das Script und scheitert im ersten Anlauf schon an dem erstellen der ersten Testseite scheitert. Was hab ich getan, ganz einfach das Dingen weggeworfen. Ich wollte Webseiten erstellen nicht Doku lesen, dannn hab ich WB installiert und ohne einmal in die Anleitung zu schauen eine Seite erstellt. Mit 10 minuten in die Doku schauen ein Template gebaut. Und nach ner halben Stunde lesen ein Modul gebaut und direkt noch eine Core Modifikation Nachgeschoben... einfach GEIL.
Irgendwie fällt mir da der Spruch einen CMS Jüngers von einem anderen CMS ein:
--- Code: ---Hmmm jaaaa, das ist nicht intuitiv aber Du musst ja nur das hier im Wiki lesen und dann das hier in der Doku und vieleicht noch hier die Tutorials machen, dann ist alles gaaaanz einfach.
--- End code ---
Und wenn ich denke wie sich ein Einsteiger fühlt der das erste mal in ein Template mit Loops, Verzweigungen und
Includes anschaut dann ist das bestimmt schlimmer als meine ersten Erfahrungen mit C64 Basic. Zumal ich das Damals aktiv lernen wollte.
Es ist schön alles machen zu können, ohne Doku. Warum ist Apple so erfolgreich? Weil es so intuitiv ist, man brauch nicht lesen sondern kann machen. Und obendrein kann man mit so einem MAC auch noch alles tun was man mit einem vollwertigen UNIX Server anstellen kann, weils ein FreeBSD ist (Gut, erst wenn man ein paar Limits entfernt hat. :lol:) So sollte es werden.
cwsoft:
@Norhei
Naja für die meisten Sachen dürfte ne einfache Platzhalterersetzun g reichen, sprich {{ PLATZHALTER }}, das versteht jeder. Darüber hinaus noch IF, ELSE Konstrukte und der LOOP. Alles andere (z.B. Includes, Vererbung, Funktionen ...) sind Goodies die man nutzen kann, aber nicht muss. Ich denke in 90% der Fälle wird ein Template nicht komplexer als dieses hier werden. Die wichtigsten Twig Sprachkonstrukte kann man auch auf den Hilfeseiten mit Beispielen zeigen.
Bei WB Templates muss man auch ein paar Sachen lernen. Zum Beispiel wie man register frontend nutzt, loginboxen anzeigt, oder viel schwieriger sein Menü mit show_menu2 und CSS nach eigenem Gusto anpasst.
Ist aber wie alles im Leben eine Frage des Geschmackes.
NorHei:
jep showmenu() könnte was zum vereinfachen gebrauchen
easyuser:
Kleiner Exkurs zu Beginn:
Eine meiner interessantesten und lehrreichsten Erfahrungen mit Programmierung war das Leiten von Programmierern im Rahmen eines Projekt-Workshops. Ziel war es, in drei Tagen ein CMS zu programmieren. Wie war egal.
Wie soll man nun 10 Leute gleichzeitig arbeiten lassen?
Geht nicht, also ein Design Pattern genommen. Ich habe dafür ein Faible, diesmal nicht MVC, sondern das - wie ich finde für solche Fälle beste - Entity-Control-Boundary.
2 Leute haben Datenbankzugriffe (Entity) gemacht, 5 Leute die eigentliche Programmierlogik (Control) und 3 Leute mit Twig nur HTML / CSS / jQuery / "Twig-Code" (Boundary).
Das Ende vom Lied war, dass das Projekt zwar aus den Fugen geraten ist, am Ende aber sehr sauberer, nachvollziehbarer Code vorhanden war, beliebig erweiterbar. Echo wurde gänzlich verbannt, SQL gab es nur in einer einzigen gekapselten Klasse.
Und: Die 3 Leute vom Design mit Twig haben keinen einzigen Fetzen PHP gesehen - wozu auch.
Sicher ist das eine Traumvorstellung für WB (jedenfalls für mich), und wir können nunmal WB nicht mal eben umschreiben. Es soll lediglich zeigen, dass eine TemplateEngine extrem sinnvoll ist, wenn sie von A-Z durchdacht und in das Projekt integriert ist.
Ich finde es aus dem heutigen Zeitpunkt von WB und seiner Twig-Unterstützung eher schwer, sich das richtig vorzustellen. Zugegeben, ich kenne die Twig-Unterstützung von WB nicht im Detail.
Doch - damit es nicht ganz so trocken aussieht - ein Real-Beispiel für obiges "CMS" (zugegeben, die Bezeichnung ist falsch).
Es gibt eine wrapper.htt, leicht gekürzt:
--- Code: ---<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>
{{ page.head_titel }}
</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<link rel="stylesheet" type="text/css" href="css/style.css" />
</head>
<body>
<div id="site">
<div id="top">
<div id="logo">
{{ page.titel }}
</div>{% include 'top_nav.htt' %}
</div>
<div id="content">
<div id="left">
{% block content %} {% endblock %}
</div>
<div id="right">
{% include 'sub_nav.htt' %}
</div>
</div>
</div>
<div id="bg_footer">
</div>
</body>
</html>
--- End code ---
Sie ist die Basis. Eben der Wrapper, der immer gilt. Die "Quasi - index.php" also.
Die top_nav.htt exemplarisch stellt die Navigation in einem DropDown dar:
--- Code: ---<div id="navi">
<div id="navimain">
<ul id="header_menu" class="menu">
{% for t_nav in topnav %}
<li>
<a href="{{ t_nav.Url }}" class="{{ t_nav.Current }} navlev1">{{ t_nav.Title }}</a>
</li>
{% endfor %}
</ul>
</div>
</div>
--- End code ---
Und last but not least eine richtig dargestellte Seite:
--- Code: ---{% extends "wrapper.htt" %}
{% block content %}
<h1>
Servus!
</h1>
<p>
Bitte wählen Sie in der Navigation oben aus, was Sie tun möchten.
</p>
{% endblock content %}
--- End code ---
So, det war's! Kein PHP, nada.
Sicher kann man sagen: "Warum nicht gleich PHP?".
Dann muss ich wirklich mal fragen: Was soll der Designer von heute alles können?
CSS und HTML wird hier immer als gegeben hingestellt, jQuery sowieso.
Doch alleine schon CSS ist für die meisten eine große Hürde - die Abstraktion in Zahlen ist sicher schwerer als man denkt.
Und zu dieser "künstlerischen Abstraktion" kommt noch die Programmierung dazu.
Sicher - wer sich die Mühe gemacht hat, PHP zu lernen wird blöd sein, wenn er es nicht mehr einsetzt. Oder Java, oder C#, oder JavaScript - ja, unterschätzt nicht JavaScript / ECMAScript, das wird in Umgebungen zu Zwecken eingesetzt, die man sich hier lieber nicht vorstellt. Und die Komplexität dazu auch nicht. jQuery ist auch nichts anders.
Und das ist noch lange nicht alles - für PHP und andere serverseitigen Geschichten kommt auch noch Sicherheit, Performance, Kompatibilitäten usw. ins Spiel.
Und es mag ein Klischee sein - aber ich kenne so gut wie keinen sehr guten Designer, der auch sehr gut programmieren kann. Andersrum übrigens auch nicht.
Aus oben genannten Gründen:
- Einfachheit
- Arbeitsteilung
- Leichte Dokumentierbarkeit
- Abgrenzung
finde ich eine sauber in WB integrierte Twig-Engine (meinetwegen auch eine andere, aber jetzt haben wir eine, jetzt lasst die doch mal bitte auch sein, zufriedenstellen kann man NIEMALS jeden), mit der ich auch alles ansprechen kann - vom Seitentitel über die Blöcke bis hin zu den Menüs - deutlich besser und flexibler als reines PHP.
Abschließend noch ein Wort zu Apple: Apple mag für die User ja recht angenehm sein - sie sind fast so erfolgreich wie Google mit ihrem Betriebssystem damit. Trotzdem hat Apple für die Millionen von Apps eine eigene (!!!!) Programmiersprache namens Objective-C 2.0 entwickelt (gut, zwischenzeitlich war der Vorgänger bei BSD, aber... das ist ja bekannt). Und das Faß Microsoft will ich gar nicht erst aufmachen.
Noch Fragen?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version