tools für generierung von statischen webpages

ronny

hi - ich tue mich grade schwer ein nettes tool zu finden, mit dem man recht angenehm statische webpages erstellen kann, die aus einigen unterseiten bestehen

kennt wer evtl eins ?

Wirklich easy: Microsoft Expression Web (http://www.microsoft.com/germany/expression/web/default.mspx)

Standardkonform und einfach zu bedienen.

http://schmidt-webdesign.net/

Headhunter

Das übliche Problem bei statischen Seiten ist: Man hat ne Navi, nen Header, evtl. auch nen Footer und eben dynamischen Content. Preisfrage: Wie macht man daraus eine dynamische Seite ohne in jede Contentseite Header usw. einzufügen oder Frames zu benutzen?
Ich helfe mir in solchen Fällen immer mit einer hässlichen PHP Frickellösung (mh.. hässliche PHP Frickellösung.. ist ja fast schon mehr als doppelt gemoppelt):

<?
$frame = implode ("\n", file('frame.tpl'));
$file = implode ("\n", file('index_content.html'));

$text = str_replace ('$title', 'Header', $frame);
echo str_replace ('$content', $file, $text);
?>

minhen

Headhunter schrieb:

Das übliche Problem bei statischen Seiten ist: Man hat ne Navi, nen Header, evtl. auch nen Footer und eben dynamischen Content. Preisfrage: Wie macht man daraus eine dynamische Seite ohne in jede Contentseite Header usw. einzufügen oder Frames zu benutzen?

Antwort: man verwendet XSLT.
Dann muss man auch nicht ständig HTML-Code schreiben sondern fasst sich kurz in XML. Um die Umsetzung in (X)HTML kümmert sich dann der lokal installierte XSLT-Prozessor (z.B. Xalan). Man hat also weniger Arbeit und weniger Redundanz. Und das beste ist: die Seite bleibt auf dem Webspace statisch, da man sie auch lokal auf dem eigenen Desktop-Rechner erzeugen kann und dann nur noch die erzeugten Seiten hochladen muss. Wer's dynamisch will kann's natürlich auch dynamisch haben. Webserver können ebenfalls XSL-Transformationen durchführen
Und mehr als einfache Übersetzungen kann man mit XSLT auch machen. Ich hab's z.B. bei meiner privaten Webseite so, dass sobald mehr als drei Abschnitte in einer Seite vorkommen, am Anfang der Seite voll automatisch ein kleines, verlinktes Inhaltsverzeichnis generiert wird.
Und mehr noch - man kann die Seiten auch lokal direkt im Browser testen ohne Webserver oder Zusatzprogramme: graphische Browser können heute eigentlich alle bereits XSLT. Einen Komfort den man bei sämtlichen Textersetzungslösungen z.B. und gerade mit PHP nicht hat
Es is a Traum :xmas1:

Reyx

@minhen
Nur mal rein technisch:
Was ist bei der Methode so viel besser, als wenn ich ein PHP-Skript schreibe und die statischen Resultate dann auf den Server hochlade? Abgesehen von "Webserver/Zusatzprogramme", wie du es bezeichnest? Die meisten Webentwickler haben doch ohnehin einen Webserver laufen, und die gängigen Sprachen sind auch meistens vefügbar (gerade wenn man sich nicht aussuchen kann, womit man programmieren/skripten soll).
Ich sehe da den praktischen Nachteil irgendwie nicht?

minhen

Wenn du lokal nen Webserver mit PHP laufen hast bzw mit PHP statische Webseiten erzeugst und auf die dann deinen Browser ansetzt gibt's keine großartigen Nachteile außer halt dass PHP ne widerliche Sprache ist. Aber da das zu einem gewissen Grad Geschmackssache ist, darf das (leider ;)) nicht als Nachteil zählen. Insofern bei den gegebenen Voraussetzungen ist's doch ok.
Wenn ich aber kein Bock hab nen Webserver lokal aufzusetzen - und das habe ich nicht* - ist's natürlich schöner wenn man mit möglichst wenig Software auskommt. Bei XSLT reicht, wie gesagt, ein Browser schon völlig aus.
Na gut, bei XSLT profitiert man natürich auch noch davon dass es ein W3C-Standard ist:

Browser (Firefox, Opera, IE) können es direkt verarbeiten
Webserver (Apache, IIS) können es direkt verarbeiten
Eigenständige XSLT-Prozessoren (Xalan) können es direkt verarbeiten

Das heißt als XSLTler kann ich mir die Variante, die mir am besten gefällt, aussuchen. Ich habe die Auswahl. Dann garantiert mir XSLT auch XML-konforme Dokumente, was bei XHTML schon mal ganz nett ist. Dann ist XSLT natürlich zwar anders aber einfach in der Anwendung: ich schreibe einfach hin was für ein Ergebnis ich haben will und muss keinen Gedanken daran verschwenden wie das Ergebnis berechnet wird. Das macht der XSLT-Prozessor für mich. Also auch ganz bequem.
Aber wie gesagt, wenn du auf PHP stehst, kannst es natürlich auch mit PHP machen. Nur die Variante von Headhunter ist nun wirklich nicht gerade ideal ...

* Für was? Meine statischen Sachen für Webserver ohne dynamische Inhalte erzeuge ich mit XSLT und dynamisch arbeite ich direkt im CMS aufm Ziel-Server. Wofür verfügt denn ein modernes CMS über die Möglichkeit mehrere Versionen zeitgleich zu verwalten von denen nur die fertige online geschaltet ("published") ist ... wenn ich nicht gerade ein CMS entwickel oder einen Server betreibe habe ich keinen Grund einen Webserver zu installieren.

Reyx

Mhh ... Unter dem Gesichtspunkt hört sich XSLT für mich in der Tat äußerst interessant an; ich glaube, da muss ich mich mal einarbeiten

Headhunter

Wie sieht deine XSLT browserbasierte Variante aus, wenn der User Agent kein XSLT versteht? Stichwort GoogleBot...

minhen

Headhunter schrieb:

Wie sieht deine XSLT browserbasierte Variante aus, wenn der User Agent kein XSLT versteht? Stichwort GoogleBot...

Ich habe aus gutem Grund explizit davon geredet einen XSLT-Prozessor anzuwenden oder XSLT vom Webserver ausführen zu lassen. Suchmaschinen sind nur ein Grund weswegen man nicht XSLT direkt ausliefern sollte.
Ich denke das ich hab deutlich genug gesagt:

man kann die Seiten auch lokal direkt im Browser testen

Aber schön dass dir aufgefallen ist, dass es dämlich wäre sein XML direkt rauszuhauen. (Ich hatte schon genug Diskussion bei denen die Leute absolut nicht einsehen wollten, weswegen XSLT auf die Server-Seite und nur dort hin gehört und aufm Client nichts verloren hat. Insofern wirklich )

ronny

ich dachte eher an eine nette kombination aus menü generator und quelldateien aus simplifizierten markup und ein paar metainformation über lesbaren namen und position im menü

da xml nicht nett ist, (weil es nicht als human editable format gedacht ist)
und php einfach nur mist ist

*edit*

ich will die page auf einen sehr leistungsbegrenzten webserver packen, deswegen ist jede art von dynamisch auf dem server zuviel

Mit nem Texteditor.

minhen

r0nny schrieb:

da xml nicht nett ist, (weil es nicht als human editable format gedacht ist)

Was für ein absoluter Blödsinn. Hast du jemals in deinem Leben mit XML gearbeitet? Es steht schon klipp und klar im XML-Standard:

The design goals for XML are:
(...)
* XML documents should be human-legible and reasonably clear.
(...)

außerdem

* XML documents shall be easy to create.

Meine private Webseite sieht zum Beispiel so aus:

<?xml version="1.0" encoding="utf-8"?>
<page xmlns="http://meineurl">
	<meta>
		<title>Programmname</title>
		<language>de</language>
		<description>Blabla</description>
		<category>program</category> <!-- für Generierung des Menüs -->
	</meta>
	<content>
		<section title="Überschrift, Programmname">

			<text>Blablablabla und noch mehr blabla was das Programm macht und so...</text>

			<qinfo>
				<name>Programmname</name>
				<version>1.0.0</version>
				<filename>blubb</filename> <!-- für Links zu Changelogs und Dokumentation -->
				<features>
					<f>tolles Feature 1</f>
					<f>tolles Feature 2</f>
					<f>tolles Feature N</f>
				</features>
			</qinfo>

			<download>
				<platform id="windows">
					<link>
						<url>programm.zip</url>
						<text>Ich bin der Downloadlink für Windows</text>
					</link>
					<link>
						<url>http://irgendwo/programm.zip</url>
						<text>Ich bin ein Mirror für Windows</text>
					</link>
				</platform>
				<platform id="unix">
					<link>
						<url>programm.tar.gz</url>
						<text>Ich bin der Downoadlink für Unix</text>
					</link>
				</platform>
			</download>

		</section>
	</content>
</page>

Dann geht einmal kurz XSLT drüber, generiert Menüs und Textbausteine (beim Download und "Quickinfo") und erzeugt eine wunderschöne XHTML-Ausgabe. Bei "normalen Textseiten" sind auch mehrere <section>s vorhanden - sind es mehr als drei verlinkt XSLT die Überschriften und generiert eine Inhaltsangabe am Anfang des Dokuments. Verschachtelungen werden natürlich berücksichtigt.
Einfacher geht's doch gar nicht mehr.

ronny

imho ist das nicht gut lesbar

mit yaml oder tdl wäre das wesentlich besser lesbar

ich will keine bescheuerten xml/html tags, sondern einfach nur ein simples markup was schnell schreibbar und gut lesbar auch ohne xml-highlighter ist

das nerft echt - kommt nochmal wer mit einem guten vorschlag der nicht wieder im xml-hype endet, oder muss ich das ganze selber basteln

zum vergleich:

kategorie über den ordner, sprache über prefix an der datei

title=Steckbrief MeinProg
---
= Programmname
* Version: 0.0.1
* [Documentation:http://mydomain/myprog/docs/]

Bla bla bla was es halt so macht ...

== Download

=== Linux

http://mydomain/myprog/myprog-0.0.1.tgz

=== Windows

http://mydomain/myprog/myprog-0.0.1.zip

*edit*
PS wenn ihr euch angepisst fühlt - ich fühl mich angepisst wenn ich nach möglichst simplifizierten lösungen suche und dann so featuremonster wie xml und xslt vorgeworfen bekomm die nur mehr schreibarbeit bei 0 gewinn für mich bedeuten

haha jetzt ist minhen sprachlos :p

HTML ist doch eine Sprache zum "generieren" von formatiertem Text. Wieso brauch ich jetzt noch ne Sprache zum "generieren" von HTML.

ronny

html ist nur eine markup sprache für dokumente

html wurde nicht dafür entwickelt um von menschen editiert zu werden, auch wenn wir heutzutage dort angekommen sind

cheopz

wenn ihr euch angepisst fühlt - ich fühl mich angepisst wenn ich nach möglichst simplifizierten lösungen suche und dann so featuremonster wie xml und xslt vorgeworfen bekomm die nur mehr schreibarbeit bei 0 gewinn für mich bedeuten

Dann nimm einen Wiki auf PHP-Basis, den du mit einem lokalen Webserver bearbeitest und gieße den ganzen Wiki zur Veröffentlichung in statische HTML-Dateien (das sollte nicht allzu schwierig sein).

Was du da als "Markup" haben willst, entspricht ohnehin der gängigen Wiki-Syntax.