Mailinglisten-Archive |
Hallo Oliver,
> Die Motivation dazu ist aus dem Alltag heraus für mittlere bis größere
> Projekte auch ersichtlich, allerdings erscheint die "reine" Aufteilung in
> Komponenten und Logik auch wiederum kaum alltagstauglich, denn das
> visuelle Erscheinen der Seiten ist dann doch begrenzt oder eingeschränkt.
>
> Beispiel: wenn Coder und Designer an einem Projekt in GoLive (oder DW,
> egal) zusammenarbeiten, dann gibt es natürlich ganz verschiedene
> Schwerpunkte bei der Arbeit: die eine Gruppe arbeitet "visuell" am HTML-
> Code, die andere Gruppe arbeitet an der "Ablauf"-Logik.
> Letztendlich diktiert allerdings http mit seinen Verweisen, daraus online
> wieder eine Einheit zu bilden, warum also das nicht auch in der
> Produktion versuchen? (zumal beide Gruppen dadurch ein besseres
> Verständnis für die Arbeit der anderen Gruppe entwickeln)
Klappt das wirklich? Ich kenne größere Projekte wo der Einsatz
"intelligenter"
Template-Systeme an den Webdesignern gescheitert ist. Die haben diese
komischen
"Kommentare" in Quelltext gesehn, sich geärgert, wer da wohl ihren schönen
aufgeräumten HTML Krams verunstaltet hat und dann kurzerhand das HTML
wieder
"sauber" gemacht *hihi* Sicher ... in solchen Fällen könnte es nichts
schaden,
vorher mit dem Gesamtteam eine Art internen Workshop über die verwendete
Technik
zu machen. Dann wissen alle, woran sie sind. Ob das geschehen ist oder
nicht,
bzw. warum nicht, kann ich nicht sagen. Waren (Gott sei Dank) nicht meine
Projekte ;o)
> Im Einsatz haben wir deshalb eine Template-Klasse, die im HTML-Code (also
> zwischen <html> und </html>) Platzhalter für Texte, Grafiken oder Links
> in Form von Pseudotags setzt und darüber hinaus noch if-then-else-
> Konstrukte innerhalb einer Seite zuläßt - nach dem </html>-Tag kommt dann
> unmittelbar in der Seite die dafür zuständige Ablauflogik, die dann die
> Platzhalter entsprechend füllt/auswählt/verfielfältigt etc.
>
> Vorteil:
> - weitgehend visuelles Layouten
> - keine Überschneidungen von Designer/Programmierern
> - konventionelle Site-Management mit dem Vorteil, dass GoLive z.B. alle
> statischen Links automatisch korrigiert
> - schnell, da keine Template-Komponenten nachgeladen werden müssen
> - noch schneller :) , da nur mit str_replace (keine reg. Exp) gearbeitet
> wird - mächtig: exklusive Layoutgruppen innerhalb einer Seite, dyn./
> geschachtelte Blöcke, post-processing von Cookies oder allg. aller
> Header-Direktiven
Das klingt schick. Und schnell ist es auch? Weil ich hätte jetzt vermutet,
daß der "Template-Interpreter", der die Konstrukte im Template lesen und
ausführen soll, das Ganze ausbremst ...
> Nachteil:
> - Caching ist noch nicht eingebaut (benötigten wir in unseren bisherigen
> Projekten noch nicht)
Hm, so häufig wird Caching auch nicht gebraucht. Man sollte es als reine
Server-
lösung (Zend-Cache, Apache-Lösungen) auf jeden Fall im Repertoire haben,
aber
es wird viel Wind um solche Dinge gemacht. Wenn ich ein DB-Frontend für den
Intranetgebrauch mache, dann kann ich das gar nicht so CPU-lastig coden, daß
es die paar Clients nicht mehr verträgt ... sag ich jetzt mal so.
> - die Extension für GoLive zum D&D der Platzhalterobjekte ist noch nicht
> fertig
Sowas könnte ich als IDE-Allergiker ja noch verschmerzen ;o)
Viele Grüße,
Volker Göbbels
---
Arachnion GmbH & Co. KG Dr. Volker Göbbels
Business Communication vmg_(at)_arachnion.de
Gouleystr. 59 Tel. +49 (0) 2405 42477-0
52146 Würselen Fax +49 (0) 2405 42477-2
Web Application Development, Consulting, Linux HA Cluster
Kompetenz in Unix: http://www.arachnion.de
php::bar PHP Wiki - Listenarchive