Antworten: 24
|
|||||||
 TheSorcererBeginner Herkunft: Gelnhausen Beiträge: 16 |
# Thema - 25.05.2009 um 05:12 Uhr
Ich bin mir nich gänzlich sicher ob mein Beitrag in diesem Thread richtig aufgehoben ist. Ich bitte also um Verzeihung falls ich diesen Aufruf mißverstanden habe. Ich habe bezüglich der Theme Platzhalter eine ganze Reihe von Vorschlägen - und wäre auch gerne bereit diese mit Code zu unterstützen. Aber zunächsteinmal möchte ich anregen in Erwägung zu ziehen auf ein Templatesystem Dritter zurückzugreifen. Smarty ist hervorragend, bietet alle Features die Clansphere besitzt und eine ganze Menge mehr. Es ermöglicht sich künftig auf andere Aspekte bei der Clansphere Weiterentwicklung konzentrieren zu können. Es ist natürlich immer schwer sich von - vor allem selbsgeschriebenen - Code zu trennen, aber, wenn man genügend Vorteile daraus ziehen kann sollte man es zumindest in Erwägung ziehen. Falls das Entwicklerteam allerdings kein Interesse an einer solchen Codenutzung hat wären folgende Dinge imo mittelfristig unverzichtbar für eine Leistungsstarke Template Engine: Mehr "Systeminformationen" Innerhalb der Templates stehen nur vergleichsweise wenige Informationen zum aktuellen User, Login, Session, etc zur Verfügung. zB ist die Information darüber ob ein User zur Zeit eingeloggt ist oder über welchen Zugriffslevel er verfügt in vielen Anwendungen unverzichtbar. Diese Informationen stehen zur Zeit nicht global in allen Templates / Themes zur Verfügung. Ein Beispiel:
Das Beispiel führt auch gleich zum nächsten Punkt Mächtigere Kontrollstrukturen Die aktuelle Bedingungsabfrage ist gut gemeint, aber den meisten Fällen absolut ungenügend. Ohne ein vorheriges "Vorkauen" der ggf schon zur Verfügung stehenden Daten sind keine Kontrollstrukturen in den Themes möglich. Es wäre ein enormer Vorteil, wenn Kontrollstrukturen a) variable Vergleichsoperatoren hätten (ggf auch komplexere Operatoren wie zB isempty, length, etc) b) auf den gesamten Datensatz zugreifen könnten (und nicht bloß auf $data['if']-Daten) c) komplexere Verzweigungen alá else und elseif beherrschen Außerdem sollten die Bezeichner des Template Platzhalter vereinheitlicht werden. Es gibt keinen Grund dafür beim schließenden loop Tag den Loop Bezeichner erneut zu nennen ({stop:loopname}  , außerdem sollten schließende Tags angeben welchen Typ sie schließen ({stop:bla} kann ein {if:bla} oder ein {loop:bla} schließen).Beispiel
Modifikatoren / Formatierungen In vielen Anwendungen ist es durchaus sinnvoll Rohdaten noch zu formatieren bevor diese Dargestellt werden. Dabei macht es durchaus Sinn die Formatierung in die Templates zu verlagern, denn nicht die Datenbasis soll verändern werden, sondern nur die Art der Darstellung der Daten. Darum sollte die Template Engine eine Reihe von Modifikatoren und Formatveränderungen zur Verfügung stellen. Beispiel:
Ich freue mich auf Resonanz! Wie gesagt, falls Interesse an einer so erweiterten Funktionialität besteht wäre ich auch gerne bereit Code beizutragen. *Ausgeschnitten aus Thread: Fehlende Theme-Platzhalter* |
||||||
Inaktiv |
  |
||||||
 duRiel  Weltmeister  Herkunft: Cambridge Beiträge: 7300 |
# Antwort: 1 - 25.05.2009 um 10:06 Uhr
hi! vielen dank für die vielen vorschläge, gefällt mir gut! zur stellungnahme: wir haben immer wieder überlegt, auf ein theme-system wie smarty umzusteigen, und haben uns immer wieder dagegen entschieden. hauptgrund dafür ist, dass wir nicht wollen, dass unsere themes als eigene programmiersprache enden. sie soll so einfach sein, dass jemand mit wenig html erfahrung daran basteln kann, am besten auch schon in frontpage/dreamweaver etc. bei smarty ist eine einarbeitungszeit nötig, die viele nicht haben oder nicht aufwenden wollen. für viele ist die homepage immerhin nur eine zweck-sache, nicht alle wollen ihre zeit damit verbringen. die trennung vom code würden wir/ich über das herz bringen, auch wenn ich das theme system gerade erst komplett neu geschrieben habe (auf oop basis, aber mit gleicher funktionalität bis auf dynamische sql abfragen. um die ging es übrigens in dem thread, in dem du geschrieben hast). Mehr "Systeminformationen" ich stimme zu! Mächtigere Kontrollstrukturen else gibt es bereits seit einiger zeit. ob elseif nötig ist weiß ich nicht, weil das ja nur das code layout etwas verändert und nichts an funktionalität bringt. mit den zugriffen auf die variablen und eigenen kontrollen statt der simplen übernahme der im php geprüften bedingungen hast du recht. da wird man aber etwas basteln müssen. allerdings würde ich hier wieder darauf aufpassen, dass es nicht zu sehr richtung code geht. !isempty finde ich schon kritisch. das mit den bezeichnungen der bedingungen im theme sehe ich nicht so. warum ist es logischer, den typ der schließenden bedingung zu benennen und nicht den namen der bedingung? da sehe ich von der logik her keinen unterschied. und von der umsetzung her ist das mit den namen natürlich viel einfacher, da es sonst probleme mit der verschachtelung gibt, wenn man da nicht notlösungen bastelt. haben wir übrigens auch so für verschachtelte quotes, ist nicht so schön umzusetzen. Modifikatoren / Formatierungen ich stimme zu! über das format der platzhalter mit modifikatoren lässt sich natürlich streiten, aber das kann man ja noch später überdenken. gruß duRiel |
||||||
Inaktiv |
 |  |
||||||
| TheSorcerer Thread-Ersteller Beginner Herkunft: Gelnhausen Beiträge: 16 |
# Antwort: 2 - 25.05.2009 um 11:08 Uhr
25.05.2009 um 10:06 Uhr - duRiel: Mächtigere Kontrollstrukturen mit den zugriffen auf die variablen und eigenen kontrollen statt der simplen übernahme der im php geprüften bedingungen hast du recht. da wird man aber etwas basteln müssen. allerdings würde ich hier wieder darauf aufpassen, dass es nicht zu sehr richtung code geht. !isempty finde ich schon kritisch. Gerade eine derartige Abfrage hilft aber enorm. Es macht schon einen großen Unterschied ob man eine leere Tabelle vom Template generiert bekommt oder eine Meldung erhält, dass keine Datensätze vorhanden sind. Dies wäre im Moment nur durch entsprechende Vorarbeit im PHP Quelltext möglich. Und das ist unschön, vor allem, wenn man Webdesigner möglichst vom PHP abkapseln möchte. das mit den bezeichnungen der bedingungen im theme sehe ich nicht so. warum ist es logischer, den typ der schließenden bedingung zu benennen und nicht den namen der bedingung? da sehe ich von der logik her keinen unterschied. und von der umsetzung her ist das mit den namen natürlich viel einfacher, da es sonst probleme mit der verschachtelung gibt, wenn man da nicht notlösungen bastelt. haben wir übrigens auch so für verschachtelte quotes, ist nicht so schön umzusetzen. Es gibt mehrere Gründe dafür den Typen zu nennen: 1. Man erkennt welche Kontrollstruktur man gerade schließt. Im Moment muss man sich anhand des Namens der Kontrollstruktur merken um welche Kontrollstruktur es sich handelt (if?, loop?, was auch immer?). 2. Wenn man darauf verzichten möchte den Namen der Kontrollstruktur im schließenden Tag erneut zu nennen - was man nicht sollte, denn es ist technisch unnötig und bietet imo keinen Gewinn, außerdem würde es mit komplexeren Bedingungen unmöglich werden, da diese keine Bezeichner mehr hätten, wie die aktuellen Bedingungen - wird es geradezu für die Übersicht notwendig den Typen der Kontrollstruktur zu bennen. Es sei denn man steht auf LISP-Like Klammerirrgärten. 3. "Die Anderen machen es auch so!" In jeder mir geläufigen Markup/Script Language wird der Typ der Struktur im abschließenden Element genannt und nicht der Name des Elements. Es heißt ja auch nicht <html id="main_html"> ... </main_html> in XHTML oder if a = 1 then a = 2 end a = 1 in VBS und mit Traditionen sollte man nur mit gutem Grund brechen. Im übrigen gibt es keine Probleme mit den regulären Ausdrücken, solange die abschließenden Elemente greedy gesucht werden. Mit den aktuellen (lazy) regulären Ausdrücken dürfte es durchaus Probleme geben wenn abschließende Elemente nicht eindeutig bezeichnet sind, da bei einem Konstrukt wie
sonst das erste auftretende {endif} als Ende für das erste auftretende {if} gefunden würde. Mit greedy Regex findet er immer die zwei äußeren Elemente, die zwangsläufig zusammengehören müssen, denn Kreuzverschachtelungen sind weder möglich noch ergeben sie einen logischen Sinn. Ich habe sowieso noch nicht verstanden warum an einigen Stellen lazy Konstrukte benutzt werden, obwohl sie dort imo weder nötig noch - in diesem Zusammenhang - zuträglich sind. PS: bla - vergiss was ich zu den regulären Ausdrücken gesagt habe - so einfach ist es warscheinlich doch nicht:
Mit greedy Operatoren findet er hier nur ein if Konstrukt. Allerdings sollte es auch dafür eine Lösung geben. Und es gibt sie doch nicht: http://stackoverflow.com/questions/133601/can-regular-expressions-be-used-to-mat ch-nested-patterns Da fragt man sich wie ich letztes Semester in Theoretische Informatik/Formale Sprachen eine zwei hab schreiben können
Zuletzt editiert von TheSorcerer am 25.05.2009 um 11:39 Uhr (2x Editiert) |
||||||
Inaktiv |
| |
||||||
| duRiel Weltmeister Herkunft: Cambridge Beiträge: 7300 |
# Antwort: 3 - 25.05.2009 um 14:31 Uhr
Kontrollstrukturen ja, das finde ich ja auch. aber mit inversen zu arbeiten.. bezeichnungen der bedingungen und loops ja, das mit den nested patterns vs regex meinte ich ja gerade. da ist es für die umsetzung vorteilhaft, den namen der bedingung / des loops zu haben. den namen der kontrollstruktur kann man wie du sagtest durchaus nennen und ist auch für die umsetzung kein problem. ob das dann übersichtlicher ist weiß ich noch immer nicht.. argument "die anderen machen es auch so": was ist mit c? einfach schließende geschwungene klammer. und ich liebe c syntax. |
||||||
Inaktiv |
| |
||||||
| hajo VIP - Poster  Herkunft: Barsbüttel Beiträge: 9411 |
# Antwort: 4 - 25.05.2009 um 14:32 Uhr
smarty ist für unsere theme-behandlung einfach overpowered. es kann zwar viel nützliches, stünde aber auch in vielerlei hinsicht mit bestehenden lösungen in clansphere schon im konflikt. zudem bietet es keine klare mvc-web trennung, erlaubt sogar php in theme dateien, für mich ein unding! auch könnte man dann gleich bessere frameworks wie z.b. das von zend einsetzen. meine sogar, dass smarty kein subprojekt von php mehr ist seit es zend framework gibt, woran das wohl liegen mag  vor allem aber ist clansphere darauf bedacht, so wenig fremd-software wie nötig einzusetzen. es geht dabei nicht darum das rad neu oder nochmal runder zu erfinden, sondern eine abgerundete und komplexitätsgerechte gesamtlösung mit möglichst wenigen ansprüchen oder abhängigkeiten dritter anbieten zu können. alleine schon aus lizenstechnischen gründen leider nötig, da z.b. die gpl v3 und ähnliche bestandteile auf dauer ärger anrichten könnten und dann eh wieder entfernt werden müssten. deine vorschläge zum bestehenden system finde ich gut und stimme da großteils mit duriel überein. vielen dank dafür 
------------------ ClanSphere - professional clan care starts here |
||||||
Inaktiv |
| |
||||||
| TheSorcerer Thread-Ersteller Beginner Herkunft: Gelnhausen Beiträge: 16 |
# Antwort: 5 - 26.05.2009 um 17:20 Uhr
25.05.2009 um 14:31 Uhr - duRiel: Kontrollstrukturen ja, das finde ich ja auch. aber mit inversen zu arbeiten.. Die Negation gehört allerdings zu den logischen Grundoperationen und ist unabdingbar für eine vollwertige bedingte Verzweigung. Und auch wenn viele Leute Schwierigkeiten haben auf ein "Nicht!" zu höheren, verstehen tun es die meisten bezeichnungen der bedingungen und loops ja, das mit den nested patterns vs regex meinte ich ja gerade. da ist es für die umsetzung vorteilhaft, den namen der bedingung / des loops zu haben. den namen der kontrollstruktur kann man wie du sagtest durchaus nennen und ist auch für die umsetzung kein problem. ob das dann übersichtlicher ist weiß ich noch immer nicht.. argument "die anderen machen es auch so": was ist mit c? einfach schließende geschwungene klammer. und ich liebe c syntax. Wie du allerdings selbst sagst: dass wir nicht wollen, dass unsere themes als eigene programmiersprache enden Ich bin auch ein riesen Fan der C-Syntax, allerdings wird sie von vielen als kryptisch und unübersichtlich empfunden. Nicht gerade das Vorbild für eine einfach zu handhabende Template Engine, oder? Außerdem wäre eine Nennung des Blocktyps dadurch, dass die Blockbegrenzungstokens in C nur aus einem einzelnen Zeichen bestehen ohnehin nicht möglich. Ihr allerdings benutzt ohnehin bereits ganze Wort-Tags und nicht bloß ein einzelnes Zeichen um die Grenzen der Blöcke zu markieren. Eine Nennung des Typs wäre also ohne weiteres möglich. Solltet ihr euch dazu entschließen komplexere bedingte Verzweigungen wie zB {if:count>0}, einzuführen fiele aber ohnehin der Bezeichner im {if}-Tag weg, es sei denn man würde Ungetüme wie {stop:count>0} nutzen. Abgesehen davon, dass dies zu dem Problem führt, dass man dann je Template nur ein einziges mal auf diese bestimmte Bedingung prüfen könnte (das Problem aber existiert sogar bereits jetzt, wenn mich nicht alles täuscht) trägt dieses Konstrukt in keiner Weise zu Übersichtlichkeit, Lesbarkeit und Verständnis mehr bei. Das Einführen komplexerer Kontrollstrukturen würde damit dann auch dazu führen, dass man sich von den nicht mehr praktikablen regulären Ausdrücken zur Abarbeitung der Templates verabschieden und die Templates komplett in einen Baum parsen müsste. Allerdings ließen sich die Parse-Bäume dann cachen und somit eine Steigerung der Performance erreichen. Alternativ ließe sich der Aufwand des Template Processings eben von einer Bibliothek Dritter erledigen. smarty ist für unsere theme-behandlung einfach overpowered. es kann zwar viel nützliches, stünde aber auch in vielerlei hinsicht mit bestehenden lösungen in clansphere schon im konflikt. zudem bietet es keine klare mvc-web trennung, erlaubt sogar php in theme dateien, für mich ein unding! auch könnte man dann gleich bessere frameworks wie z.b. das von zend einsetzen. meine sogar, dass smarty kein subprojekt von php mehr ist seit es zend framework gibt, woran das wohl liegen mag Ob man Smarty, ZF oder irgend etwas anderes nutzt wäre erstmal nebensächlich. Richtig ist natürlich, dass die Einführung einer Engine Dritter zu einem Kompatibilitätsbruch führen würde. Aber auch das könnte man lösen, indem man zB die bisherige Engine als für einen weiteren Produktions Zyklus als Default Engine lässt und die neue Engine nur optional anbietet. Nach einer Weile der Umstellung könnte dann die neue Engine die alte als Default Engine ablösen. Für die Umsetzung des MVC Patterns ist das Framework als ganzes Zuständig, nicht unbedingt die Template Engine. Allerdings kann eine zu schwache Template Engine dazu führen, dass das MVC Pattern gebrochen werden muss, weil bestimmte Darstellungsfunktionalitäten nicht im Template zur Verfügung stehen. Auch wenn Clansphere im Großen und Ganzen eine sehr schöne Trennung von Daten und Darstellung bietet - der Hauptgrund, warum wir mit unserem Clan von Webspell auf Clansphere umsteigen - gibt es noch die eine oder andere Stelle in der Darstellungslogik in der Programmlogik vollzogen werden muss, weil die Template Engine zu schwach ist. Eine (zu) mächtige Template Engine bietet zwar den Anwendern die Möglichkeit das MVC Pattern auszuhebeln und zu umgehen, aber das ist imo immer noch besser als eine zu schwache Engine zu haben, die den Anwender dazu zwingt die Trennung zu umgehen. Ich habe mich mit dem Zend Framework noch nicht wirklich beschäftigt, aber wenn mich nicht alles täuscht wäre das ziehmlich mit Kanonen auf Spatzen geschossen: wir reden von einer Template Engine und keinem Application Framework. Im übrigen erlaubt das Zend Framework auch PHP in den Templates - ja ist sogar darauf angewiesen. vor allem aber ist clansphere darauf bedacht, so wenig fremd-software wie nötig einzusetzen. es geht dabei nicht darum das rad neu oder nochmal runder zu erfinden, sondern eine abgerundete und komplexitätsgerechte gesamtlösung mit möglichst wenigen ansprüchen oder abhängigkeiten dritter anbieten zu können. alleine schon aus lizenstechnischen gründen leider nötig, da z.b. die gpl v3 und ähnliche bestandteile auf dauer ärger anrichten könnten und dann eh wieder entfernt werden müssten. Wenn ihr natürlich ausdrücklich darauf verzichten wollt Fremdsoftware einzusetzen liegt das in eurem Ermessen. Hilfreich wäre es aber sicherlich, vor allem dabei sich auf die Kernabliegen von Clansphere konzentrieren zu können, nämlich ein modernes und modulares Web-CMS, zur kompletten Online-Verwaltung von Clans, Vereinen und anderen Gruppierungen zur Verfügung zu stellen. Ein mächtiger Template Parser hilft dabei enorm. Im übrigen ist Smarty LGPL lizensiert. Die Lizenz sollte also kein Argument gegen Smarty sein. Freut mich, dass ihr für meine Kritik und Vorschläge offen seid! PS: Das zensieren des Namens des anderen Clan CMS finde ich allerdings ziehmlich lächerlich - um ehrlich zu sein fast sogar anstößig. Zuletzt editiert von TheSorcerer am 26.05.2009 um 17:25 Uhr (2x Editiert) |
||||||
Inaktiv |
| |
||||||
 MindcrimeGeekboy  Beiträge: 1155 |
# Antwort: 6 - 26.05.2009 um 19:32 Uhr
Der ganze idee um templates zu haben ist um so viel wie moeglich den intelligenz/business logik/code (PHP) von das design (HTML) zu trennen. Man muss also aufpassen das man so ein template system nicht benutzt um business logik in die templates zu coden... Weil, was bringt es um alle intelligenz in die template zu coden, weil dan haette man auch gleich ein PHP page mit HTML drin machen koennen... Weil dan hat man nun anstatt nur 2 "sprachen" (PHP und HTML) noch eine extra "sprache" (SMARTY) die man lernen muss um die page zu gestalten... Ein kleines intelligentes system ist genug fuer die themes, aber mach bitte nicht ein zu heftiges system, das geht den zweck vorbei... Kleine {if expr}{fi} und {while expr} {wend} und so sind ok... Das einzige was besser waehre, ist das man die variablen mehr als klassen mit properties und functions oder so benutzen koennte... Zuletzt editiert von Mindcrime am 26.05.2009 um 19:33 Uhr (1x Editiert) |
||||||
Inaktiv |
| |
||||||
| SCHIRI Weltmeister Herkunft: Hamburg Beiträge: 5299 |
# Antwort: 7 - 26.05.2009 um 20:01 Uhr
mir gefallen die vorschläge auch sehr gut. Zur Zensierung vom Websp: Ein bischen Spaß muss sein. Ich sehe das als eine art Easteregg an. So wie auf mousesports.de die smilies Mäuseohren haben oder wenn man auf apple.com "windows" sucht auf eine seite kommt "warum ihre nächster pc ein mac sein sollte". Webspell ist ja nicht gerade ein Konkurenzprodukt. Viele unserer User sind von Webspell gewechselt weil sie damit unzufrieden sind und ich kenne niemanden der von Clansphere zu WS gewechselt ist. erlaubt sogar php in theme dateien, für mich ein unding! gewisser maßen ist php doch auch eine template-sprache.
------------------ www.laszlokorte.de Zuletzt editiert von SCHIRI am 26.05.2009 um 20:01 Uhr (1x Editiert) |
||||||
Inaktiv |
| |
||||||
| Mindcrime Geekboy Beiträge: 1155 |
# Antwort: 8 - 26.05.2009 um 20:08 Uhr
Das zensieren find ich ein bissel kindisch, WS ist halt auch ein system und einige schwoeren dabei. Es sieht aus, aus sicht einer der den code und alles nicht kennt (ich kenn den code von WS, CS und noch einige frei erhaeltige CMS systeme), als wurdet ihr neidisch sein... Man muss in prinzip froh sein das es mehrere solche systeme gibt, die man umsonst benutzen kann und jeder sein vorteil an hat... Eine gute idee in WS fuer ein modul kann ja eine anregung fuer jemand sein um so ein modul auch im CS zu machen und v.v. Aber ich bin mal total off topic (mir fehlt ein smiley fuer "off topic")... Zuletzt editiert von Mindcrime am 26.05.2009 um 20:08 Uhr (1x Editiert) |
||||||
Inaktiv |
| |
||||||
| TheSorcerer Thread-Ersteller Beginner Herkunft: Gelnhausen Beiträge: 16 |
# Antwort: 9 - 26.05.2009 um 20:54 Uhr
26.05.2009 um 19:32 Uhr - Mindcrime: Der ganze idee um templates zu haben ist um so viel wie moeglich den intelligenz/business logik/code (PHP) von das design (HTML) zu trennen. Man muss also aufpassen das man so ein template system nicht benutzt um business logik in die templates zu coden... Weil, was bringt es um alle intelligenz in die template zu coden, weil dan haette man auch gleich ein PHP page mit HTML drin machen koennen... Weil dan hat man nun anstatt nur 2 "sprachen" (PHP und HTML) noch eine extra "sprache" (SMARTY) die man lernen muss um die page zu gestalten.. Genau darum geht es ja aber. Wenn ich zB eine Liste in der Form einer Tabelle ausgeben möchte, die mit Daten aus der Tabelle gespeist wird dann sollte meine Programmlogik die Daten von der Datenbank holen, evtl strukturieren und auf eine genormte Form aufbereiten. Die Darstellung der Daten ist dann aber Sache des Templates. Also welche Farbe die Daten haben, wie groß die Tabelle ist, ob die Links in der Tabelle unterstrichen sind usw. Auch zur Darstellungslogik gehört aber auch, dass wenn die Programmlogik ein leeres Ergebnis liefert, die Darstellungslogik in der Lage sein sollte den User darüber zu informieren (zB in der Form einer "Keine Datensätze gefunden"-Meldung). Einige dieser Sachen sind mit dem aktuellen Webspell System *nicht* möglich, weil die Template Engine nicht mächtig genug ist. Man muss gewisse Daten und Informationen in der Programmlogik verarbeiten obwohl diese Dinge eindeutig in die Darstellungslogik gehören. Zur Zensierung vom Websp: Ein bischen Spaß muss sein. Ich sehe das als eine art Easteregg an. So wie auf mousesports.de die smilies Mäuseohren haben oder wenn man auf apple.com "windows" sucht auf eine seite kommt "warum ihre nächster pc ein mac sein sollte". **** ist ja nicht gerade ein Konkurenzprodukt. Viele unserer User sind von **** gewechselt weil sie damit unzufrieden sind und ich kenne niemanden der von Clansphere zu WS gewechselt ist. Ich bin jemand der viel Wert auf seine Rechte legt und reagiere gereizt wenn mir jemand den Mund verbietet. Eine solche Zensur verstehe ich als digitalen Maulkorb. Vielleicht habe ich etwas überreagiert Im übrigen noch ein wichtiger Punkt: An vielen Stellen von Clansphere wird dem Template mit cs_link ein fertiger Link übergeben. Das sollte dringend so geändert werden, dass dem Template mit cs_url eine URL und der (mögliche) Bezeichner seperat übergeben wird, damit der Designer selbstständig entscheiden möchte in welcher Form er den Link darstellen möchte. Im mom ist es zB ohne Eingriff in den PHP Code nicht möglich anstelle des Textlinks ein Bild anzuzeigen oder dem Textlink auch nur ein verändertes Style Attribut mit auf den Weg zu geben. |
||||||
Inaktiv |
| |
||||||
 NachtmeisterSpecialist  Herkunft: Bern Beiträge: 2091 |
# Antwort: 10 - 26.05.2009 um 21:12 Uhr
/agree Ich bin mir von Template Systemen wie bei Wordpress oder Drupal gewohnt, dass ich sowohl anpassbare PHP Platzhalter als auch zum teil mit rohem PHP oder vereinfachtem PHP erwitern kann. Das ermöglicht ein hoch flexibles System und man kann beinahe alles realisieren. Sogar ich, als Nicht-PHP kenner kann dann leicht nachvollziehen, sei es mit Hilfe aus dem Forum oder einer guten Dokumentation, wie ich Teile meiner Seite so realisiere, wie ich es in meiner Vorstellung habe. Wer Wordpress kennt wird zwar auch der Meinung sein, dass der Salat von HTMl und PHP furchtbar ist. Allerdings wird vom Benutzer schon abverlangt, dass er sich mit der Masse auseinander setzt, um etwas realisieren zu können damit. Schliesslich soll Autofahren auch gelernt sein und nicht einfach so einfach gemacht werden, dass es einfach jeder ohne Wissen machen kann. Von daher ein totales /agree mit deinen Vorschlägen zum Templating. Denn es ist auch Sache von Logik, wie Daten ausgegeben werden sollen und das sollte auch in tiefer Form beeinflussbar sein. ------------------ "God created the universe in 1 Day, and then spent 5 days making it look good In Internet Explorer" |
||||||
Inaktiv |
| |
||||||
| hajo VIP - Poster Herkunft: Barsbüttel Beiträge: 9411 |
# Antwort: 11 - 26.05.2009 um 22:21 Uhr
warum dann gerade php? xsl-t kann dafür ein mehr als guter ersatz sein und liefert schon nahezu alles wichtige vorweg ------------------ ClanSphere - professional clan care starts here |
||||||
Inaktiv |
| |
||||||
| Mindcrime Geekboy Beiträge: 1155 |
# Antwort: 12 - 26.05.2009 um 23:52 Uhr
26.05.2009 um 22:21 Uhr - hajo: warum dann gerade php? xsl-t kann dafür ein mehr als guter ersatz sein und liefert schon nahezu alles wichtige vorweg Argh, wenn du mit XSL-T XSL transformations (mit vielleicht XPATH) meinst, das ist wohl das schlechteste loesung.. Total unzureichend und total unuebersichtlich, daneben frisst es resourcen... Und du brauchst dan auch noch wellformed XML dateien als basis... Sorry, aber das kannst du designer nicht zumuten das die sowas machen koennen... Ich hab da meine erfahrungen... |
||||||
Inaktiv |
| |
||||||
| hajo VIP - Poster Herkunft: Barsbüttel Beiträge: 9411 |
# Antwort: 13 - 27.05.2009 um 00:03 Uhr
es wäre allerdings die sauberste und wohlgeformteste lösung, zumal man mit xsd noch eine validation durchführen kann. weiterhin ist xpath sehr mächtig und die grundzüge schnell erlernbar, auch basiert alles auf dem bekannten xml aufbau als baum und ist damit prima strukturiert. vor allem aber mag ich deklarative programmierung oder noch besser funktionale, auch wenn diese ein vielfaches an performance kostet, so ist die aufgabenstellung nicht mehr einen ablauf zu programmieren, sondern regeln aufzustellen und semantik zu erschaffen ------------------ ClanSphere - professional clan care starts here |
||||||
Inaktiv |
| |
||||||
| duRiel Weltmeister Herkunft: Cambridge Beiträge: 7300 |
# Antwort: 14 - 27.05.2009 um 03:00 Uhr
hab hajo auch noch nicht so von seiner xslt begeisterung abbringen können zum web spell verbot: ja, wir haben kein problem damit, darüber zu schreiben, sieht man ja hier, ist nur eher ein spässchen. kann aber auch weg wenn du dich dadurch eingeschränkt fühlst zu den kontrollstrukturen: ja, hast recht mit der einführung der variablen bedingungen erübrigt sich eigentlich die frage, dann muss man die verschachtelung "manuell" verfolgen im php code. mir fällt gar nicht mehr viel zu schreiben ein, ich stimme dem meisten zu. die kritik ist also angekommen und ich werde da gerne mal dran basteln. ist halt noch zu sagen dass unser theme system etwas in den kinderschuhen steckt, wir haben erst dieses jahr die komplette umstellung auf themes geschafft. werde mich da bald ran wagen. |
||||||
Inaktiv |
| |
||||||
| jokey Try to beat me  Herkunft: Hamburg Beiträge: 184 |
# Antwort: 15 - 27.05.2009 um 23:04 Uhr
25.05.2009 um 11:08 Uhr - TheSorcerer: Da fragt man sich wie ich letztes Semester in Theoretische Informatik/Formale Sprachen eine zwei hab schreiben können [/quote]Da siehst du es. Du gehst als Informatiker an die Sache ran... Die überwiegende Mehrheit der User befindet sich aber eher auf einem Niveau, dass sich mehr mit HTML als Sprache befasst. (Ich will hier keinen! diskreditieren oderso, es geht mir mehr um Tatsachendarstellung) Deswegen darfst du derart komplexe Strukturen nicht unbedingt überall anlegen... Außerdem, wenn ein System derart flexibel ist, dass es schon fast elastisch ist, benutzt es keiner mehr. Reiner Erfahrungswert aus knapp 20 Jahren IT
|
||||||
Inaktiv |
| |
||||||
 vainRock the board  Beiträge: 85 |
# Antwort: 16 - 28.05.2009 um 03:26 Uhr
Ich möchte zu einigen Sätzen aus diesem Thread etwas beisteuern: "smarty ist für unsere theme-behandlung einfach overpowered." Das sehe ich nicht so. Es kommt drauf an, welche Anforderungen an die Anwendung gestellt werden. Also geht es darum wohin ihr euch entwickeln wollt.. Aber es gibt Situationen, da kommt auch Smarty überhaupt nicht weite - ist also nicht overpowered, sondern relativ schlapp auf den Beinen. Zwei Beispiele: Einaml der Einsatz von XML im Template und als Zweites einfache Verschiebeoperationen von Untertemplates in das Haupttemplate. Für die XML Unterstützung haben wir den Befehlssatz erstmal kräftig erweitern müssen und das ganze dann in einem eigenen Dokumentenprozessor zusammengefasst, der nun darauf spezialisert ist, XML und XSLT Elemente in Smarty Templates verwendbar zu machen. Eine weitere Grenze für Smarty taucht auf, wenn man versucht eine Verschiebungsoperation aus einem Subtemplate in den Kopf oder Footer des Haupttemplates durchzuführen. Das ist nicht gerade einfach und als Smarty entworfen wurde, da hat man an sowas gar nicht gedacht. Aber nach all den Yahoo Empfehlungen soll man ja die Javascripte an den Footer verschieben usw. das abzubilden war nicht gerade einfach. Und mit der normalen Smarty-Power zwar möglich aber nicht auf einfachem Wege (Kernbohrung an der Library). Ein weiteres Problem von Smarty ist defintiv die Art und Weise des Tag-Scannings. preg_matching is langsam und frisst einfach zuviel Power. Daher verwendet Smarty zukünftig einen eigenen Parser und Lexer der auf Lemon basiert. ( http://www.hwaci.com/sw/lemon, http://smarty-php.googlecode.com/svn/branches/Smarty3Alpha/ ) An dieser Stelle sagen Kritiker natürlich, dass die Dinge damit an die Spitze getrieben werden. Ein Argument gegen Smarty ist ja immer, dass es eine neue Programmiersprache im Template ist. Richtig ist, dass man den Befehlssatz von Smarty bis an die Grenze zu PHP ausweiten kann. Mit einem Lexer+Parser könnte man prinzipiell eine komplette Programmiersprache entwickeln. Dann hätte man nichts erreicht, außer alle Funktionen von PHP mit Smarty abzubilden. Sinn der Sache ist aber den umgekehrten Weg zu gehn: im Template sollen gerade nicht alle PHP Befehle verwendbar sein. Denn ein eingeschränkter PHP Befehlssatz führt zu mehr Sicherheit im Template. Und diese wenigen Befehlselemente sollen komplexe Operationen ermöglichen und zudem noch schnell ausgelesen werden können. Und das letzte rechtfertigt zumindest den Lexer- bzw. Parsereinsatz. Wer reine PHP Templates einsetzt, der muss einfach berücksichtigen, dass man die Trennung der Anliegen im Kopf haben muss. Man kann an dieser Stelle sehr wohl den Fehler machen, die Geschäftslogik in PHP Templates einzubauen. Aber genau diesen Fehler kann man auch machen, wenn PHP in den Sicherheitseinstellungen von Smarty aktiviert ist. Da gibt esüberhaupt keinen Unterschied. Schiri hat da vollkommen Recht, wenn er sagt das PHP auch eine Templatesprache ist. Das "auch" ist das wichtige Wort. "zudem bietet es keine klare mvc-web trennung, erlaubt sogar php in theme dateien, für mich ein unding!" Smarty kann daher auch so eingesetzt werden, dass es die Trennung der Anliegen korrekt umsetzt. PHP in Templates einzusetzen ist kein Widerspruch zu diesem Verfahren. Man sollte dann aber nicht wie im alten Wordpress so machen, im Template Queries an die DB abzusetzen. "auch könnte man dann gleich bessere frameworks wie z.b. das von zend einsetzen. " Der Einsatz von Frameworks rettet auch niemanden davor, die Trennung zu durchbrechen und im Template auf die DB zuzugreifen, etc. Da kann man immernoch genügend Fehler machen. ------------------ Clansuite Maintainer  Zuletzt editiert von vain am 28.05.2009 um 03:28 Uhr (1x Editiert) |
||||||
Inaktiv |
| |
||||||
| hajo VIP - Poster Herkunft: Barsbüttel Beiträge: 9411 |
# Antwort: 17 - 28.05.2009 um 03:51 Uhr
mir geht es um eine klare verteilung von aufgaben, möchte nicht das durch php usw in templates auf einmal logik abgehandelt wird, die über das simple anzeigen von ja/nein und tabellen oder alternativ fehlermeldungen hinausgeht ------------------ ClanSphere - professional clan care starts here |
||||||
Inaktiv |
| |
||||||
| Mindcrime Geekboy Beiträge: 1155 |
# Antwort: 18 - 28.05.2009 um 13:25 Uhr
Man sollte vielleicht ein unterschied hier sehen zwisschen business logik und template/presentations logik: - Business logik ist zb die logik um herauszufinden welche unterforum ein benutzer sehen kann und das aus der datenbank holen von info's ueber diese unterforen (name unterforum, letzter thread, etc) - Template/Presentations logik ist zb die logik um bei der presentierung von die daten jede reihe (zb unterforum info) in einer tabelle eine andere farbe zu geben, oder zu nummern... Business logik gehoert nicht in die templates. Presentations logik sollte dahingegen (obwohl man auch darueber streiten kann) moeglich sein in die templates zu integrieren... Klar kann man ein sehr intelligentes template system nehmen, aber das laesst so manchmal einige programmierer die moeglichkeit offen um dan business logik in die templates einzubauen... Und vergisst wie schon gesagt bitte nicht die wichtigste vorraussetzung: Templates werden meistens/immer erstellt von DESIGNER und NICHT PROGRAMMIERER... Und ich kenne verdammt wenig DESIGNER die programmieren koennen (und andersrum). Also man sollte etwas nehmen was auch leicht zu verstehen ist fuer DESIGNER... Und damit schliesse ich in prinzip XSL-T schon aus... PS: Ich bin selber ein programmierer und kein designer |
||||||
Inaktiv |
| |
||||||
| jokey Try to beat me Herkunft: Hamburg Beiträge: 184 |
# Antwort: 19 - 28.05.2009 um 17:08 Uhr
28.05.2009 um 13:25 Uhr - Mindcrime: Und damit schliesse ich in prinzip XSL-T schon aus... PS: Ich bin selber ein programmierer und kein designer Ganz genauso sehe ich das auch. Ferner ist es einfach Masochrismus(spelling?) pur, von einem Menschen zu verlangen, XML zu schreiben. Darüber sollten wir in moderner PC Welt nun wirklich erhaben sein. |
||||||
Inaktiv |
| |
||||||
| hajo VIP - Poster Herkunft: Barsbüttel Beiträge: 9411 |
# Antwort: 20 - 28.05.2009 um 17:41 Uhr
xmlspy und co als editoren helfen da schon ungemein, zudem steht in dem xsl-t ja wiederum eh nur html und das kann man ja leicht bearbeiten. die struktur drum herum ist ja zu 99% sache der entwickler
------------------ ClanSphere - professional clan care starts here |
||||||
Inaktiv |
| |
||||||
Antworten: 24
|
|||||||
| Sie müssen sich registrieren, um zu antworten. |
