Hi,

so nachdem meine Entwicklungsumgebung funzt, wage ich mich mal wieder an ein Projekt:
Das Ganze wird prinzipiell ein CMS, ja ich weiß - gibts schon genug - aber für meine Bedürfnisse habe ich noch keines gefunden. (Bitte keine Links der unzähligen Scriptarchive posten - Danke)

Hier die grundsätzliche Frage:
Wie die Seite aufbauen lassen, und wie / wo speichern?

- Alles durch ein "navigation.cgi" das bei jedem Aufruf die entsprechende Seite zusammenbastelt. Beispielsweise mit vielen .txt's a la header.txt, navi.txt, inhalt1.txt, footer.txt.
oder ähnlich

-wie oben nur mit SSI

- Von einem "admin.cgi" die HTML-Seiten schon fertig auf den Server legen. Was ist dann mit Sachen wie der Navigation, bei einer Änderung müssten alle HTML-Seiten neu geschrieben werden.

Also, was macht Sinn, und ist von der Geschwindigkeit brauchbar, vorallem wenn auf diesem "Portal" mal mehr Traffic entsteht?

Oder doch jede Seite mit einem Script zusammenbasteln lassen, die Daten aber aus einer Datenbank holen. Prob hier: Eigentlich ist nur SDBM überall verfügbar, und da ist wohl kein großer Unterschied zum Dateihandle.

(Hab ich noch was vergessen? Oder stehe ich schon wieder mal im Wald?)

Bin gespannt...

für die seiten:
HTML::Template...
für Inhalte würde ich DBI und MySQL nehemn und diese dann wieder über HTML::Template jagen!

Quote

- Alles durch ein "navigation.cgi" das bei jedem Aufruf die entsprechende Seite zusammenbastelt.

Ja, klingt vernuenftig.

Quote

Beispielsweise mit vielen .txt's a la header.txt, navi.txt, inhalt1.txt, footer.txt.

Ja kann man so machen. Allerdings wird's dann etwas aufwaendiger wenn Du Dinge in diesen "Teilseiten" dynamisch anpassen willst (wie z.B. die Navigation). Template-Engine ist dann sinnvoller. Die Frage ob man da jetzt HTML::Template nimmt oder Text::FastCGI oder wie sie alle heissen artet meisst in Glaubenskrieg aus, also einfach checken was man braucht und ausprobieren.

Mein Meinung: HTML::Template ist meist ausreichend, aber wenn man z.B. bei IF und ELSE mehr als True und False braucht (also eher sowas wie CASE) dann ist das Teil schon gestorben. Die ganzen Frameworks wie HTML::Mason u.ae. sind mir zu aufwaendig, meist Overkill durch die extreme Featureritis und man muss meist in die Server-Konfig vom Apache eingreifen damit sie ueberhaupt laufen.

Quote

wie oben nur mit SSI

Warum den Server durch das Parsen ausbremsen und (wenn wie oben erwaehnt Teilbereiche angepasst werden muessen) X Prozesse fuer die ganzen CGIs starten wenn auch einer reicht?

Quote

- Von einem "admin.cgi" die HTML-Seiten schon fertig auf den Server legen.

Zusaetzchlich hast Du dann das Problem das die Seitengenerierung immer laenger dauert, je umfangreicher die Site wird. Irgendwann laeuft dein Update-CGI zu lange und wird vom Server abgeschossen. Dann hast Du zei Moeglichkeiten:

* Das Update als Kindprozess starten - dann bekommst Du keine direkte Rueckmeldung wann's fertig ist. Kann man per Mail einbauen, aber wenn was schieflaeuft wird's nach dem 5. Anlauf ziemlich nervig und nach dem 12. Versuch moechte man das ganze Ding am liebsten auf den Scheiterhaufen werfen und mit verzuecktem Gesicht seinen gequaelten Sterbenslauten lauschen.

* Das Update auslagern auf die Shell oder als cron. Scheitert meist am nicht vorhandenen Shellzugriff bei Mietspace und wie stoesst Du das dann an?
- Soll der cron jede Minute pruefen ob sich was geaendert hat? Admins hassen Minuten-Crons (c:
- Oder nur in Intervallen? Dann braucht man auch kein CMS und kann die Seiten lokal neu generieren und per FTP hochladen.
Beides keine optimalen Loesungen. Und waerend die Seite neu gebaut wird, kann es bei goesseren Aenderungen aus Usersicht zu Inkonsistenzen kommen, wenn er sich wiederholt zwischen neuen und alten Seiten hin- und herbewegt.

Quote

Prob hier: Eigentlich ist nur SDBM überall verfügbar, und da ist wohl kein großer Unterschied zum Dateihandle.

Da DBMs (ausser mit Zusatzmodul) keine verschachtelten Daten sondern nur flache Hashes speichern koennen, wuerde ich dann doch eher die Textdateien vorschlagen.

Andererseits: wenn Du eine DB wie z.B. MySQL benutzt wie es mittlerweile fast alle CMS tun, sparst Du dir einen Haufen arbeit, da sich ein grosser Teil der Aufgaben mit SQL nun mal viel bequemer loesen laesst und dir die Daten auch gleich so liefert wie du sie haben willst (vorsortiert, im passenden Datumsformat, etc).

Und wieso eigentlich "ueberall"? Ich denke das Teil ist fuer deinen persoenlichen Gebrauch? Oder willst Du so oft mit deiner Site umziehen? Selbst wenn: Welcher Provider traut sich denn noch Webpakete mit eigenen CGIs anzubieten wo nicht mindestens eine MySQL-DB dabei ist?

grundsaetzlich am schnellsten sind statische html-Seiten. wenn du damit das, was du willst, nicht abbilden kannst, waere mod_perl (sehr kompliziert) die wohl schnellste loesung. wenn du jedoch ein sauberes cgi-script hast, kannst du das, wenn es mal gut funktioniert, auch meistens recht einfach nach mod_perl umschreiben.
HTML::Template ist ein einfaches, aber recht flottes Templating System. Ich verwende es z.B. auch fuer das neue Board auf http://develop.perl-community.de/

@Cremator:

Super, vielen Dank für diese ausführliche Antwort. Also liege ich da schon richtig mit meinem Vorhaben. Werde mich wohl mal mit HTML::Template auseinandersetzten. Weiß jemand zufällig eine gute (verständliche) Beschreibung für einen Templatenewbie?

auf HTML::Template, Uebersetzung habe ich mal begonnen, das auf Deutsch zu uebersetzen. sonst hilft immer: HTML::Template

Du bist echt der Hit! Habe mir das gerade zu Gemüte geführt, scheint nicht wirklich schwer zu sein.

Ein Frage noch:
Damit baue ich ja letztlich auch wieder "schnelle" HTML Seiten.

Was mache ich aber in einem größeren Webauftritt mit Mainfootern oder headern und vor allem mit der Navigation. Sollte hier eine Änderung stattfinden, müssten ja dann unzählige Temlates geöffnet und neu geschrieben werden (wenn auch nur einmalig).
Gibt es hier dann nur den Weg über z. B. Include virtual oder solche Dinge? Also ich meine das ich die Navigation in einer Datei habe und bei Änderungen nur diese bearbeitet werden muss, und sich trotzdem auf alle Templates auswirkt. Wie macht ihr so was in der Praxis?

du kannst auch mit HTML::Template andere templates includen...
du könntest z.b. eine template.tpl machen...

Uup's ja, da waren meine Finger wieder mal schneller als mein Kopf. Jetzt hab ich es kapiert.

Vielen Dank.

Wie ist das mit der Geschwindigkeit?
Also beim kurzen überfliegen meiner noch wirren Vorstellungen werd ich ca. 6 Templates includen müssen (bei jedem Seitenaufruf) plus eine Variable die dann individuell den eigentlichen Inhalt zusammstellt.

Habe ich bei dieser Aufgabe immer noch den Geschwindigkeitsvorteil?

sollte gut sein...
kostet ja nicht zu viel cpu, das ganze...