Re: Webserver mit Stilblaettern?

[Arno Welzel]

Stefan Ram, 2023-01-23 21:54:

> Ich hatte früher für Verbindungen zu Stilblättern einen
> absoluten Pfad mit dem Stilblatt in einem extra "css"-
> Verzeichnis bevorzugt.

"Stilblätter"?

> <link rel="stylesheet" type="text/css" href="http://userpage.fu-berlin.de/~ram/pub/css/stycona.css" title="stycona" />

Ach so... Du meinst Stylesheets ;-)

> . Heute finde ich es schöner, wenn das Stilblatt im selben
> Verzeichnis liegt und ein relativer Pfad verwendet wird.
> Ich verwende also jetzt bei meinem neuen System:
>
> <link rel="stylesheet" type="text/css" href="stycona" title="stycona" />
>
> . Dabei habe ich diese Möglichkeit von Apache genutzt,
> für stycona in der .htaccess einen Typ zuzuweisen:
>
> <Files stycona>
> ForceType text/css
> </Files>

Was aber höchst irritierend ist, da außer Dir niemand weiß, dass
"stycona" ein Stylesheet ist.

> . Die anderen Dateien in dem Verzeichnis haben ja den Typ
> "text/html".

Nein, nicht "die anderen" sondern nur die mit der Endung ".html" oder
".htm".

> Das ich meinen als Hobby programmierten statischen
> Seitengenerator vielleicht einmal auch für andere zugänglich
> machen will, frage ich mich, ob diese Vorgehensweise so
> allgemein brauchbar wäre, oder ob es vielleicht bei anderen

Nein!

Wenn man die Dateien mal offline ohne Webserver betrachten will, ist es
grober Unfug, Stylesheets in Dateien ohne Endung abzulegen.

Lass es doch einfach so, wie es ist - also ".css" für Stylesheets und
das "title"-Attribut braucht man ebenfalls nicht:

<link rel="stylesheet" type="text/css" href="stycona.css" />


--
Arno Welzel
https://arnowelzel.de

[Peter J. Holzer]

On 2023-01-23 20:54, Stefan Ram <r...@zedat.fu-berlin.de> wrote:
> Ich hatte früher für Verbindungen zu Stilblättern einen
> absoluten Pfad mit dem Stilblatt in einem extra "css"-
> Verzeichnis bevorzugt.
>

><link rel="stylesheet" type="text/css" href="http://userpage.fu-berlin.de/~ram/pub/css/stycona.css" title="stycona" />
>

> . Heute finde ich es schöner, wenn das Stilblatt im selben
> Verzeichnis liegt und ein relativer Pfad verwendet wird.

Ich finde das unpraktisch. Meine Websites haben typischerweise Dutzende
oder hunderte Directorys:

trintignant:~/wrk/www/www.hjp.at 22:27 :-) 1054% find . -type d | wc -l
1057
trintignant:~/wrk/www/www.hjp.at 22:31 :-) 1055% pd ../wwg.hjp.at/public
/home/hjp/wrk/www/wwg.hjp.at/public
trintignant:~public 22:31 :-) 1056% find . -type d | wc -l
812
trintignant:~public 22:31 :-) 1057% pd ~/wrk/luga/luga.at-master/www/luga-hugo/public
/home/hjp/wrk/luga/luga.at-master/www/luga-hugo/public
trintignant:~public 22:32 :-) 1058% find . -type d | wc -l
368

Ich will aber nicht hunderte Stylesheets warten müssen. Selbst wenn die
automatisch generiert werden, sehe ich wenig Sinn darin, hunderte -
vermutlich großteils identische - Stylesheets herumliegen zu haben, die
der Browser dann auch einzeln herunterladen muss.
Falls ich wirklich für (fast) jede Seite ein eigenes maßgeschneidertes
Stylesheet generieren möchte, würde ich den letzten Schritt auch noch
gehen und die HTML-Files gleich mit einem <style>...</style> Abschnitt
generieren.

> Ich verwende also jetzt bei meinem neuen System:
>
><link rel="stylesheet" type="text/css" href="stycona" title="stycona" />
>
> . Dabei habe ich diese Möglichkeit von Apache genutzt,
> für stycona in der .htaccess einen Typ zuzuweisen:
>
><Files stycona>
> ForceType text/css
></Files>
>

> . Die anderen Dateien in dem Verzeichnis haben ja den Typ
> "text/html".
>

> Das ich meinen als Hobby programmierten statischen
> Seitengenerator vielleicht einmal auch für andere zugänglich
> machen will, frage ich mich, ob diese Vorgehensweise so
> allgemein brauchbar wäre, oder ob es vielleicht bei anderen

> Webservern als Apache schwierig ist, in einem Verzeichnis
> HTML- und CSS-Ressourcen zu mischen, wenn diese keine
> Namenserweiterungen wie ".html" oder ".css" haben.

Bei NginX müsste man den Mime-Type für jedes File extra angeben, wenn
ich die Doku richtig interpretiere (ich habe es nicht getestet).

Kann man machen, aber wozu?

> Falls das ein Problem sein sollte, was wäre dann empfehlenswert?

Ein weniger exzentrisches Setup verwenden?

hp

[Helmut Richter]

On Mon, 23 Jan 2023, Stefan Ram wrote:

> Ich hatte früher für Verbindungen zu Stilblättern einen
> absoluten Pfad mit dem Stilblatt in einem extra "css"-
> Verzeichnis bevorzugt.
>
> <link rel="stylesheet" type="text/css" href="http://userpage.fu-berlin.de/~ram/pub/css/stycona.css" title="stycona" />
>
> . Heute finde ich es schöner, wenn das Stilblatt im selben
> Verzeichnis liegt und ein relativer Pfad verwendet wird.

> Ich verwende also jetzt bei meinem neuen System:
>
> <link rel="stylesheet" type="text/css" href="stycona" title="stycona" />

Alles Geschmacksache, Hauptsache bei mir: nicht durcheinander, sondern an
definierten Orten. Bei mir ists:

Seitenspezifische „Stilblätter“ im gleichen Verzeichnis oder einem
direkten Oberverzeichnis, wo die Seite liegt, webserverglobale in einem
Unterverzeichnis der „Dokumentenwurzel“, wo das meiste davon liegt, was
der Benutzer zwar einsehen könnte, aber nirgends angeboten bekommt.
Und was ihm nicht angeboten wird, kann dann auch eine Namenserweiterung
haben.

> . Dabei habe ich diese Möglichkeit von Apache genutzt,
> für stycona in der .htaccess einen Typ zuzuweisen:
>
> <Files stycona>
> ForceType text/css
> </Files>
>
> . Die anderen Dateien in dem Verzeichnis haben ja den Typ
> "text/html".

Finde ich extrem fehleranfällig. Bei jeder neuen Seite und jedem neuen
Stylesheet muss man die Konfiguration ändern. Ich finde es viel robuster,
wenn alle Dateien ihren Typ in der Namenserweiterung mit sich führen. Die
Seiten, die angeboten werden, heißen dann eben intern „index.html“ oder
„index.txt“, werden aber mit ihrem Verzeichnispfad angeboten, so dass die
Namenserweiterung nicht sichtbar ist.

Also: Das Dokument /a/b/c ist entweder die Datei /a/b/c/index.html
(Normalfall) oder /a/b/c/index.txt (seltene Ausnahme); der Benutzer kennt
sie aber als /a/b/c und das bleibt auch, wenn sich der Typ ändert. Die
Abkürzung /a/b/c.html, die per Konfiguration auch eingestellt werden kann,
habe ich neulich hier diskutiert und dann endgültig verworfen, weil zu
wenig einheitlich und deswegen zu fehleranfällig.

> PS: Mein neuer statischer Seitengenerator ist erst ganz am Anfang.
> Derzeit nimmt er eine Textdatei und macht daraus HTML,
> aber noch ohne irgendwelche besonderen Formatierungen.

Habe ich auch mal gemacht, aber anschließend festgestellt, dass andere
auch schon die Idee hatten (markdown).

--
Helmut Richter

[Michael Uplawski]

Moin.

Ich antworte hier, weil es mir leichter fällt, nicht um Peters Beitrag zu
qualifizieren. Die anderen Antworten sind IMO ebenso korrekt und nützlich.

Mon, 23 Jan 2023 22:47:42 +0100 / Peter J. Holzer:

>> . Heute finde ich es schöner, wenn das Stilblatt im selben
>> Verzeichnis liegt und ein relativer Pfad verwendet wird.
>
> Ich finde das unpraktisch. Meine Websites haben typischerweise Dutzende
> oder hunderte Directorys:

„Schöner” ist das in der Tat nur im HTML Kopf. Ich empfinde den Ansatz mit
dem Generator immer als Rückschritt, nachdem man mit Stylsheets schon die
Fehlerquellen reduziert hat und eine überschaubare Organisation erreicht.

Es ist lange her, aber ich habe immer die Meinung vertreten, dass
generierte Sachen nicht gewartet werden, sondern weggeschmissen und neu
generiert gehören. Die Fehler, die dabei beseitigt werden, haben ihren
Ursprung zwangsläufig im Generator. Dann kann ich aber nicht mehr vom
HTML-Schreiben als Hobby sprechen.

> Ich will aber nicht hunderte Stylesheets warten müssen. Selbst wenn die
> automatisch generiert werden, sehe ich wenig Sinn darin, hunderte -
> vermutlich großteils identische - Stylesheets herumliegen zu haben, die
> der Browser dann auch einzeln herunterladen muss.

Ebent. Wie eben bemerkt, muss ein Generator sich auf Sachen beschränken,
wo die manuelle Wartung keine Forderung ist. Nein. „Muss” ist sicher
übertrieben, aber der Gedanke ist schon wichtig.

> Falls ich wirklich für (fast) jede Seite ein eigenes maßgeschneidertes
> Stylesheet generieren möchte, würde ich den letzten Schritt auch noch
> gehen und die HTML-Files gleich mit einem <style>...</style> Abschnitt
> generieren.

Dito. So ist das.
... So sehe ich das. Oder: Hat immer so funktioniert und anders war es
immer @!%$$¹@>; !!!

> Kann man machen, aber wozu?

Wenn man Generatorschreiben als Hobby bezeichnet und auf Output keinen
Wert legt.

>> Falls das ein Problem sein sollte, was wäre dann empfehlenswert?
>
> Ein weniger exzentrisches Setup verwenden?

Philosophisch ist das alles interessant. Die Probleme fangen an, wenn
wenige Gleichgesinnte Gruppendynamik entwickeln und das Wesentliche aus
den Augen verlieren. Am Ende kommen dann irgendwelche Eumel heraus.., wie
“Maybe-HTML” 5.

Shoot at will.

Michael



--
Le progrès, ce n'est pas l'acquisition de biens. C'est l'élévation de
l'individu, son émancipation, sa compréhension du monde. Et pour ça il
faut du temps pour lire, s'instruire, se consacrer aux autres.
(Christiane Taubira)

[Stefan Froehlich]

On Mon, 23 Jan 2023 22:35:43 Arno Welzel wrote:
> Stefan Ram, 2023-01-23 21:54:

>> <link rel="stylesheet" type="text/css" href="stycona" title="stycona" />

>> <Files stycona>
>> ForceType text/css
>> </Files>

> Was aber höchst irritierend ist, da außer Dir niemand weiß, dass
> "stycona" ein Stylesheet ist.

Ja, das war auch mein erster Gedanke.

Andererseits ist es durchaus gängig, für den Mime-Typ text/html
URIs zu verwenden, die nicht auf HTML enden (sondern gar keine
Endung haben). Wo ist letztendlich der Unterschied?

Ok, die URIs für HTML-Seiten bekommt der Endanwender angezeigt,
diejenigen für Stylesheets nicht. Aber so what?

Selber würde ich das freilich nicht nachmachen wollen.

> Wenn man die Dateien mal offline ohne Webserver betrachten will,
> ist es grober Unfug, Stylesheets in Dateien ohne Endung abzulegen.

Übel wird es, sobald man auf die Idee kommt, HTML- und CSS-Dateien
mit dem gleichen Namen zu versehen...

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan konnte immer schon mehr als Freude machen!
(Sloganizer)

[Helmut Richter]

On Tue, 24 Jan 2023, Stefan Froehlich wrote:

> Übel wird es, sobald man auf die Idee kommt, HTML- und CSS-Dateien
> mit dem gleichen Namen zu versehen...

Ich stelle gerade in der umgekehrten Richtung um: mehrere verschiedene
Dateiendungen für text/html, je nach Einsatzzweck: .html für angebotene
Webseiten; .ssi für HTML-Text, der in viele Seiten mittels SSI eingebunden
wird und so parametrisiert ist, dass er sich überall an seine Umgebung
anpasst; .htdata für Teile von Seiten, die getrennt gepflegt werden, z.B.
Tabellen, die zu anderen Zeitpunkten fortgeschrieben werden als der
umgebende Text.

--
Helmut Richter

[Peter J. Holzer]

On 2023-01-24 05:30, Michael Uplawski <michael....@uplawski.eu> wrote:
> Mon, 23 Jan 2023 22:47:42 +0100 / Peter J. Holzer:
>>> . Heute finde ich es schöner, wenn das Stilblatt im selben
>>> Verzeichnis liegt und ein relativer Pfad verwendet wird.
>>
>> Ich finde das unpraktisch. Meine Websites haben typischerweise Dutzende
>> oder hunderte Directorys:
>
> „Schöner” ist das in der Tat nur im HTML Kopf. Ich empfinde den Ansatz mit
> dem Generator immer als Rückschritt, nachdem man mit Stylsheets schon die
> Fehlerquellen reduziert hat und eine überschaubare Organisation erreicht.

Ich nicht. Eine Website enthält viele repetitive Elemente (z.B.
Navigation), die sich unter Umständen auch oft ändern (z.B. wenn eine
Seite dazukommt, muss die in diversen anderen Seiten eingefügt werden).
Das ist manuell mühsam, sobald man mehr als eine Handvoll Seiten hat.
Da ist ein Generator sehr hilfreich.

> Es ist lange her, aber ich habe immer die Meinung vertreten, dass
> generierte Sachen nicht gewartet werden, sondern weggeschmissen und neu
> generiert gehören.

Ja, natürlich. Gewartet wird der *Input* des Generators, nicht der
*Output*.

Es war mir aber nach Stefans Beschreibung nicht klar, wie der Input des
Generators aussieht: Hat er ein Stylesheet, das er editiert (vielleicht
nicht in CSS geschrieben, sondern in SASS oder einer anderen Sprache),
aus dem er dann ein CSS-File pro Directory generiert? Oder hat er auch
im Input in jedem Directory ein Stylesheet? Beides halte ich nicht für
ideal.

> Die Fehler, die dabei beseitigt werden, haben ihren Ursprung
> zwangsläufig im Generator. Dann kann ich aber nicht mehr vom
> HTML-Schreiben als Hobby sprechen.

Einen Generator zu schreiben ist nicht das gleiche wie HTML zu
schreiben. Aber man muss mindestens genauso viel über HTML wissen, um
einen (guten) Generator zu schreiben. Und meistens wird man in den
Generator irgendein Templating einbauen, das wieder mit HTML gefüttert
werden will, also schreibt man dann erst wieder HTML.

hp

[Peter J. Holzer]

On 2023-01-24 11:12, Helmut Richter <hr.u...@email.de> wrote:
> On Tue, 24 Jan 2023, Stefan Froehlich wrote:
>> Übel wird es, sobald man auf die Idee kommt, HTML- und CSS-Dateien
>> mit dem gleichen Namen zu versehen...

Der URL kann nicht gleich sein. Die letzte Komponente natürlich schon,
sinnvoll ist das wohl eher selten, könnte aber z.B. vorkommen, wenn man
für jeden Abschnitt einer Website ein eigenes Stylesheet hat:

/
/style
/common
/about
/events
...
/about
/what-we-do
/who-we-are
/events
/grand-opening
...

Hier wäre dann /style/about vom Typ text/css, /about aber text/html.

So eine URL-Struktur würde ich aber eher in einer Datenbank ablegen als
im Filesystem.

> Ich stelle gerade in der umgekehrten Richtung um: mehrere verschiedene
> Dateiendungen für text/html, je nach Einsatzzweck: .html für angebotene
> Webseiten; .ssi für HTML-Text, der in viele Seiten mittels SSI eingebunden
> wird und so parametrisiert ist, dass er sich überall an seine Umgebung
> anpasst; .htdata für Teile von Seiten, die getrennt gepflegt werden, z.B.
> Tabellen, die zu anderen Zeitpunkten fortgeschrieben werden als der
> umgebende Text.

Sind diese Endungen auch Teil des URLs oder werden sie nur vom Webserver
ausgewertet, damit er weiß, was er machen soll?

Ich vermeide wenn möglich Endungen in URLs, zumindest solche, die ich
"Implementations-Details" ansehe. Ob der Inhalt als statisches HTML-File
oder als HTML-File mit ein bisschen SSI-Postprocessing auf der Platte
liegt oder ob er durch ein PHP- oder CGI-Script erzeugt wird (ja, ich
weiß, das schließt sich nicht aus) oder sonst irgendwie generiert wird,
geht den User nichts an und sollte für ihn nicht sichtbar sein. Ein URL
sollte sich nicht deshalb ändern, weil ich irgendwas an der Technik
ändere.

hp

[Helmut Richter]

On Tue, 24 Jan 2023, Peter J. Holzer wrote:

> On 2023-01-24 11:12, Helmut Richter <hr.u...@email.de> wrote:

> > Ich stelle gerade in der umgekehrten Richtung um: mehrere verschiedene
> > Dateiendungen für text/html, je nach Einsatzzweck: .html für angebotene
> > Webseiten; .ssi für HTML-Text, der in viele Seiten mittels SSI eingebunden
> > wird und so parametrisiert ist, dass er sich überall an seine Umgebung
> > anpasst; .htdata für Teile von Seiten, die getrennt gepflegt werden, z.B.
> > Tabellen, die zu anderen Zeitpunkten fortgeschrieben werden als der
> > umgebende Text.
>
> Sind diese Endungen auch Teil des URLs oder werden sie nur vom Webserver
> ausgewertet, damit er weiß, was er machen soll?

Letzteres nicht, denn der Browser interessiert sich nur für Dateiinhalt
und Typ, nicht für den Namen und die Endung.

URLs von Seiten, die dem Benutzer angeboten werden, haben gar keine
Endungen; sie sind also technikunabhängig. Ich habe auch schon mit dem
Gedanken gespielt, die Endungen aktiv wegzuwerfen: weiß der Benutzer den
Dateinamen mit Endung, wird er umgeleitet auf den „offiziellen Namen“
ohne Endung – bis jetzt nicht implementiert. Dann kann man auch nicht
ausprobieren, welche Endung *auch* funktioniert.

> Ich vermeide wenn möglich Endungen in URLs, zumindest solche, die ich
> "Implementations-Details" ansehe.

Ja.

--
Helmut Richter

[Helmut Richter]

On Tue, 24 Jan 2023, Helmut Richter wrote:

> On Tue, 24 Jan 2023, Peter J. Holzer wrote:

> > Sind diese Endungen auch Teil des URLs oder werden sie nur vom Webserver
> > ausgewertet, damit er weiß, was er machen soll?
>
> Letzteres nicht, denn der Browser interessiert sich nur für Dateiinhalt
> und Typ, nicht für den Namen und die Endung.

Gefragt war aber nach dem Webserver. Der interessiert sich für die Endung,
wenn daraus der Typ ermittelt werden kann. Dann aber gibt es für ihn keinen
Unterschied zwischen verschiedenen Endungen, die zum gleichen Typ führen. Die
Unterscheidung verschiedener Endungen wie beschrieben informiert nur den
menschlichen Bearbeiter, wozu und wie die Dateien gebraucht werden. Hilfreich
ist das auch für Skripten, die Konsistenz überprüfen, also etwa Regeln, dass
jede HTML-Datei irgendwelche Inhalte enthalten muss. Sowas gilt nicht für
Dateien vom Typ text/html, die nur Bruchstücke von Webseiten enthalten, die
woanders eingebaut werden.

--
Helmut Richter

[Arno Welzel]

Stefan Froehlich, 2023-01-24 11:12:

> On Mon, 23 Jan 2023 22:35:43 Arno Welzel wrote:
>> Stefan Ram, 2023-01-23 21:54:
>>> <link rel="stylesheet" type="text/css" href="stycona" title="stycona" />
>
>>> <Files stycona>
>>> ForceType text/css
>>> </Files>
>
>> Was aber höchst irritierend ist, da außer Dir niemand weiß, dass
>> "stycona" ein Stylesheet ist.
>
> Ja, das war auch mein erster Gedanke.
>
> Andererseits ist es durchaus gängig, für den Mime-Typ text/html
> URIs zu verwenden, die nicht auf HTML enden (sondern gar keine
> Endung haben). Wo ist letztendlich der Unterschied?

Ich rede nicht von der URI, sondern der *Datei*, die dafür benutzt wird.

Und *dafür* ist es nicht üblich, pauschl text/html anzunehmen, wenn
keine Endung vorliegt.

[Arno Welzel]

Helmut Richter, 2023-01-24 12:12:

Ja, so machen Webserver das ja auch - zumindest bezogen darauf, wie sie
die *Dateien* behandeln, die sie ausliefern sollen. Wenn man die URI
direkt 1:1 auf das Dateisytem abbildet.

[Arno Welzel]

Helmut Richter, 2023-01-24 23:36:

[...]

> URLs von Seiten, die dem Benutzer angeboten werden, haben gar keine
> Endungen; sie sind also technikunabhängig. Ich habe auch schon mit dem
> Gedanken gespielt, die Endungen aktiv wegzuwerfen: weiß der Benutzer den
> Dateinamen mit Endung, wird er umgeleitet auf den „offiziellen Namen“
> ohne Endung – bis jetzt nicht implementiert. Dann kann man auch nicht
> ausprobieren, welche Endung *auch* funktioniert.

Das ist auch ok - wenn man das *nicht* auch im Dateisystem so macht,
sondern einzig durch entsprechende Regeln im Webserver, die ggf. die
dazu benötigten Dateienamen inklusive Endung bilden - oder eben ein CMS
oder Script, was sich darum kümmert.

Eine *Datei* ohne ".css" abzulegen, obwohl sie explizit Stylesheets
enthält, halt ich aus genannten Gründen für wenig sinnvoll.

[Stefan Froehlich]

On Wed, 25 Jan 2023 11:09:47 Arno Welzel wrote:
> Stefan Froehlich, 2023-01-24 11:12:
>> On Mon, 23 Jan 2023 22:35:43 Arno Welzel wrote:
>>> Stefan Ram, 2023-01-23 21:54:
>>>> <link rel="stylesheet" type="text/css" href="stycona" title="stycona" />

>>> Was aber höchst irritierend ist, da außer Dir niemand weiß, dass
>>> "stycona" ein Stylesheet ist.

>> Andererseits ist es durchaus gängig, für den Mime-Typ text/html
>> URIs zu verwenden, die nicht auf HTML enden (sondern gar keine
>> Endung haben). Wo ist letztendlich der Unterschied?

> Ich rede nicht von der URI, sondern der *Datei*, die dafür benutzt
> wird.

Ah, ok. Ich hatte bei meinem Posting die URI im Hinterkopf, wobei:

> Und *dafür* ist es nicht üblich, pauschl text/html anzunehmen,
> wenn keine Endung vorliegt.

...ich auch hier keinen grundsätzlichen Unterschied zwischen HTML
und Stylesheet sehe: Sofern eines davon in einem Dateisystem liegt,
sollte es dort eine Extension haben, *kann* aber in der URI ohne
diese angegeben werden - letzteres scheint mir aber bei Stylesheets
extrem unüblich zu sein, bei Webseiteh hingegen durchaus gängig
(ohne dass ich natürlich im Einzelfall sagen kann, welche Seite ein
File ist und welche on-the-fly generiert wird).

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Worauf man sich verlassen kann! Stefan - Wer's glaubt!
(Sloganizer)

[Michael Uplawski]

Tue, 24 Jan 2023 18:48:28 +0100 / Peter J. Holzer:

> Einen Generator zu schreiben ist nicht das gleiche wie HTML zu
> schreiben. Aber man muss mindestens genauso viel über HTML wissen, um
> einen (guten) Generator zu schreiben. Und meistens wird man in den
> Generator irgendein Templating einbauen, das wieder mit HTML gefüttert
> werden will, also schreibt man dann erst wieder HTML.

Herzlichen Dank für diese Erwiderung. Damit kann ich auch konstruktiv
werden, und nicht bloß nörgeln... ;)

Generator + Template wäre praktisch eine Antwort an den OP. Das können wir
gerne noch weiter ausführen, aber die Zentralisierung, das Vermeiden von
Redundanz, also von Fehlerquellen und die *einfache Wartung* werden damit
erledigt.

Cheerio.

[Arno Welzel]

Michael Uplawski, 2023-01-25 13:44:

> Tue, 24 Jan 2023 18:48:28 +0100 / Peter J. Holzer:
>
>> Einen Generator zu schreiben ist nicht das gleiche wie HTML zu
>> schreiben. Aber man muss mindestens genauso viel über HTML wissen, um
>> einen (guten) Generator zu schreiben. Und meistens wird man in den
>> Generator irgendein Templating einbauen, das wieder mit HTML gefüttert
>> werden will, also schreibt man dann erst wieder HTML.
>
> Herzlichen Dank für diese Erwiderung. Damit kann ich auch konstruktiv
> werden, und nicht bloß nörgeln... ;)
>
> Generator + Template wäre praktisch eine Antwort an den OP. Das können wir
> gerne noch weiter ausführen, aber die Zentralisierung, das Vermeiden von
> Redundanz, also von Fehlerquellen und die *einfache Wartung* werden damit
> erledigt.

JFTR:

<https://fahrradzukunft.de> arbeitet mit eine Art "Generator". D.h. es
wird kein CMS benutzt, sondern Artikel werden primär als Text mit etwas
HTML angereichert abgelegt. Der "Generator" kümmert sich dann darum, aus
diesen Artikeldateien zusammen mit Templates für das Grundgerüst und
einigen typografischen Anpassungen sowie einer speziellen Behandlung von
internen Verlinkungen (Fußnoten, Literaturhinweise, Querverweise auf
andere Artikel), Bildern und Tabellen das fertige HTML-Ergebnis zu erzeugen.

Der Generator ist dabei aber effizient genug, dass das Ergebnis nicht
statisch irgendwo liegen muss, sondern erst erzeugt wird, wenn jemand
auf eine URL zugreift. Selbst das Archiv, was dynamisch aus den Inhalten
in <https://fahrradzukunft.de/archiv> erzeugt wird, braucht nur ca. 0,6s
Ladezeit, wenn man eine ausreichend schnelle Anbindung hat.

[Michael Uplawski]

Wed, 25 Jan 2023 15:07:53 +0100 / Arno Welzel:

> <https://fahrradzukunft.de> arbeitet mit eine Art "Generator". D.h. es
> wird kein CMS benutzt, sondern Artikel werden primär als Text mit etwas
> HTML angereichert abgelegt. Der "Generator" kümmert sich dann darum, aus
> diesen Artikeldateien zusammen mit Templates für das Grundgerüst und
> einigen typografischen Anpassungen sowie einer speziellen Behandlung von
> internen Verlinkungen (Fußnoten, Literaturhinweise, Querverweise auf
> andere Artikel), Bildern und Tabellen das fertige HTML-Ergebnis zu
> erzeugen.

Sowas ähnliches habe ich ja selber schon öfter gemacht. Das geht zwar bei
mir nicht dynamisch, sondern statische Seiten werden auf Anforderung
hochgeladen, aber das Prinzip der Generierung sollte identisch sein. Mein
Skript ist allerdings sicherlich primitiver als das von
fahrradzukunft.de : ich habe eine minimalistische Auszeichnung vorgesehen,
mit der Links und Themen in einem sonst beliebig formatierten Text
gekennzeichnet werden. Tagesdaten werden strikt als dd.mm.yyyy erwartet
und dannn macht mein Skript eine chronologische Liste von angekündigten
Ereignissen daraus. Die Dokumentation besteht aus: « Schickt mir das als
Text und schreibt \u vor die Links.» Ω

Freilich ist der HTML-Anteil fast komplett im Template verankert. Ich bin
erstaunt, dass mein Ruby-Skript knapp 300 Zeilen lang ist. Es liest sich
einfacher, oben... und aktuell habe ich exakt keine einzige Anwendung
dafür. Eigentlich schade.

Cheerio

[Peter J. Holzer]

On 2023-01-25 08:59, Helmut Richter <hr.u...@email.de> wrote:
> On Tue, 24 Jan 2023, Helmut Richter wrote:
>> On Tue, 24 Jan 2023, Peter J. Holzer wrote:
>> > Sind diese Endungen auch Teil des URLs oder werden sie nur vom
>> > Webserver ausgewertet, damit er weiß, was er machen soll?
>>
>> Letzteres nicht, denn der Browser interessiert sich nur für Dateiinhalt
>> und Typ, nicht für den Namen und die Endung.
>
> Gefragt war aber nach dem Webserver. Der interessiert sich für die
> Endung, wenn daraus der Typ ermittelt werden kann. Dann aber gibt es
> für ihn keinen Unterschied zwischen verschiedenen Endungen, die zum
> gleichen Typ führen.

Das ist aber nicht notwendigerweise der Fall. Du hast SSI erwähnt: Die
mir bekannten Server, die das unterstützen können alle auf Grund der
Dateiendung entscheiden, ob sie SSI auf ein File anwenden wollen oder
nicht - das Ergebnis ist in beiden Fällen text/html, aber was der Server
macht, um dorthin zu gelangen, ist durchaus unterschiedlich.

Und auch Files mit Endungen .php und .cgi resultieren oft in text/html -
aber aus Sicht des Servers unterscheiden sich die noch mehr.

hp

[Peter J. Holzer]

On 2023-01-25 12:44, Michael Uplawski <michael....@uplawski.eu> wrote:
> Tue, 24 Jan 2023 18:48:28 +0100 / Peter J. Holzer:
>> Einen Generator zu schreiben ist nicht das gleiche wie HTML zu
>> schreiben. Aber man muss mindestens genauso viel über HTML wissen, um
>> einen (guten) Generator zu schreiben. Und meistens wird man in den
>> Generator irgendein Templating einbauen, das wieder mit HTML gefüttert
>> werden will, also schreibt man dann erst wieder HTML.
>
> Herzlichen Dank für diese Erwiderung. Damit kann ich auch konstruktiv
> werden, und nicht bloß nörgeln... ;)
>
> Generator + Template wäre praktisch eine Antwort an den OP.

Warum Antwort? Daran arbeitet er ja. (Zumindest an einem Generator - ob
der auch Templates können wird, hat er uns nicht verraten, aber ohne
wäre die Zielgruppe doch ziemlich eingeschränkt.)

hp

[Peter J. Holzer]

On 2023-01-25 10:17, Arno Welzel <use...@arnowelzel.de> wrote:
> Helmut Richter, 2023-01-24 23:36:

>> URLs von Seiten, die dem Benutzer angeboten werden, haben gar keine
>> Endungen;
>

> Das ist auch ok - wenn man das *nicht* auch im Dateisystem so macht,

Prinzipiell könnte man das durchaus auch im Filesystem so machen. Es ist
kein Naturgesetz, dass der File-Typ durch die letzten paar Zeichen im
Filenamen signalisiert wird. Aber man braucht halt dann einen anderen
Mechanismus - und wenn der mit verschiedenen Webservern und auf
verschiedenen Filesystemen funktionieren soll, wird die Auswahl ziemlich
klein.

hp

[Arno Welzel]

Peter J. Holzer, 2023-01-25 19:21:

> On 2023-01-25 08:59, Helmut Richter <hr.u...@email.de> wrote:
>> On Tue, 24 Jan 2023, Helmut Richter wrote:
>>> On Tue, 24 Jan 2023, Peter J. Holzer wrote:
>>>> Sind diese Endungen auch Teil des URLs oder werden sie nur vom
>>>> Webserver ausgewertet, damit er weiß, was er machen soll?
>>>
>>> Letzteres nicht, denn der Browser interessiert sich nur für Dateiinhalt
>>> und Typ, nicht für den Namen und die Endung.
>>
>> Gefragt war aber nach dem Webserver. Der interessiert sich für die
>> Endung, wenn daraus der Typ ermittelt werden kann. Dann aber gibt es
>> für ihn keinen Unterschied zwischen verschiedenen Endungen, die zum
>> gleichen Typ führen.
>
> Das ist aber nicht notwendigerweise der Fall. Du hast SSI erwähnt: Die

Doch, ist es - immer.

> mir bekannten Server, die das unterstützen können alle auf Grund der
> Dateiendung entscheiden, ob sie SSI auf ein File anwenden wollen oder
> nicht - das Ergebnis ist in beiden Fällen text/html, aber was der Server
> macht, um dorthin zu gelangen, ist durchaus unterschiedlich.

Auch SSI hat einen MIME-Type - zwingend. Denn nur so kann ein Handler
dafür ermittelt werden. Der Handler kann ggf. in der Antwort den Typ
ändern, der dann zum Client geschickt wird, aber in erster Linie wird er
über den zugeordneten Typ ausgewählt.

> Und auch Files mit Endungen .php und .cgi resultieren oft in text/html -
> aber aus Sicht des Servers unterscheiden sich die noch mehr.

Auch .php und .cgi haben einen MIME-Type, der nicht "text/html" ist.
Dass sie ihrerseits in der Antwort "Content-Type: text/html" senden
können, ändert daran nichts.

[Peter J. Holzer]

On 2023-01-25 21:00, Arno Welzel <use...@arnowelzel.de> wrote:
> Auch SSI hat einen MIME-Type - zwingend. Denn nur so kann ein Handler
> dafür ermittelt werden.

Du verwechselst die Implementation eines bestimmten Webservers mit einem
Naturgesetz.

hp

[Michael Uplawski]

Wed, 25 Jan 2023 19:24:12 +0100 / Peter J. Holzer:

> Warum Antwort? Daran arbeitet er ja. (Zumindest an einem Generator - ob
> der auch Templates können wird, hat er uns nicht verraten, aber ohne
> wäre die Zielgruppe doch ziemlich eingeschränkt.)

Ich habe aus der Beschreibung der Seitenkonstruktion und der individuellen
Zuweisung von stylesheets geschlossen, dass es keine Templates gibt.

Zitat: „Er soll mein bisheriges System ablösen, welches derzeit noch
> darauf basiert, daß die Webseiten in Word geschrieben und
> dann mit einem selbstgeschriebenen VBA-Programm nach HTML
> gewandelt werden“.

Cheerio

[Peter J. Holzer]

On 2023-01-25 21:00, Arno Welzel <use...@arnowelzel.de> wrote:

> Auch SSI hat einen MIME-Type - zwingend. Denn nur so kann ein Handler
> dafür ermittelt werden.

Ein gewisser Arno Welzel war da in <jqgj4k...@mid.individual.net>
anderer Meinung:

| [Handler] werden nicht für MimeTypes registriert sondern Dateiendungen

hp

[Arno Welzel]

Peter J. Holzer, 2023-01-26 20:33:

Aus den Dateiendungen ergibt sich der Type. Zu finden in /etc/mime.types.

Siehe auch <https://wiki.debian.org/MIME/etc/mime.types>

[Arno Welzel]

Peter J. Holzer, 2023-01-26 00:38:

Ja, bei NGINX kann man *auch* man Handler für URLs mit bestimmten
Endungen angeben.

SSI wird tortzdem auch über den MIME-Type geregelt:

<http://nginx.org/en/docs/http/ngx_http_ssi_module.html>

Siehe "ssi_types" und was man da genau angibt.

[Claus Reibenstein]

Das ist so nicht richtig.

Linux kümmert sich von Haus aus nicht um Dateiendungen. Es gibt aber
einige Anwendungen, die sich zum Teil darum kümmern, und es gibt auch
eine Zuordnung von Dateiendungen zu Mime-Typen. Dies ist aber nur _ein_
Weg, den (Mime-)Typ einer Datei zu ermitteln.

man file
man -k mimetype

Gruß
Claus

[Peter J. Holzer]

On 2023-01-27 13:17, Claus Reibenstein <crei...@gmail.com> wrote:
> Peter J. Holzer schrieb am 26.01.2023 um 20:33:
>
>> On 2023-01-25 21:00, Arno Welzel <use...@arnowelzel.de> wrote:
>>
>>> Auch SSI hat einen MIME-Type - zwingend. Denn nur so kann ein Handler
>>> dafür ermittelt werden.
>>
>> Ein gewisser Arno Welzel war da in <jqgj4k...@mid.individual.net>
>> anderer Meinung:
>>
>> | [Handler] werden nicht für MimeTypes registriert sondern Dateiendungen
>
> Das ist so nicht richtig.
>
> Linux kümmert sich von Haus aus nicht um Dateiendungen. Es gibt aber
> einige Anwendungen, die sich zum Teil darum kümmern,

Es geht hier um Anwendungen, genauer gesagt um Webserver. Im aktuellen
Thread um beliebige Webserver, in dem alten Zitat um Apache.

hp

[Helmut Richter]

On Wed, 1 Feb 2023, Stefan Ram wrote:

> Ich fand die Idee, mehrere Stilregelsammlungen im Gebrauch zu
> haben, zunächst überraschend.

Es gibt einige Anlässe, mehr als ein Stylesheet auf einem Server zu
verwenden:

1. unterschiedliche Textgattungen: ein Inhaltsverzeichnis zu einem mehrere
Webseiten umfassenden Werk ist eine andere Textgattung als der Text des
Werkes, eine kommentierte Bildergalerie als eine Sammlung auszufüllender
Formulare. Es kann gute Gründe geben, da manche Stilentscheidungen
verschieden zu gestalten. Dann hat man eine Grund-Stil, der für eine
gewisse Einheitlichkeit und Wiedererkennbarkeit („corporate design“)
sorgt, und Stilelemente für bestimmte Textgattungen. – Natürlich kann man
die auch alle in dieselbe Datei schreiben und die unterschiedlichen Stile
zu Attributen einer Klasse zu machen, die dann Attribut des <body>-Tags
wird und somit für alle Elemente unterhalb des <body>-Elements gilt, je
nachdem, was übersichtlicher darzustellen und leichter zu pflegen ist.

2. unterschiedliche Umgebungen: wenn man etwa exakte Beschreibungen einer
Software („reference manual“), Einführungsschriften („user’s guide“) für
neue oder nur sporadische Benutzer neben Beispielsammlungen („use cases“)
für häufige Anwendungsfälle hat, kann der Nutzer durch geringfügige
Stiländerungen (Farbton des Hintergrunds, Farbe der Überschriften)
zwischen den Bereichen leichter erkennen, wie die gerade gelesenen Seite
einzuordnen ist. Ebenso, wenn es passwortgeschützte Bereiche für eine
ausgesuchte Klientel gibt: da soll auch der Nutzer leicht erkennen können,
dass er woanders ist als sonst. Der letzte Satz des vorigen Punktes gilt
auch hier.

3. spezielle Stilmittel: Wenn etwa bei den Beispielen in einem Grammatikbuch
die Subjekte andersfarbig dargestellt werden sollen als Verben, Objekte
und Adverbien, muss man entsprechene Klassen definieren, die für alle
solchen Artikel dieselben sind, die aber in anderen Artikeln gar nicht
gebraucht werden. Die gehören in ein Stylesheet nur für die einschlägigen
Artikel und nicht in ein server-globales.

--
Helmut Richter

[Arno Welzel]

Stefan Ram, 2023-02-01 16:35:

> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>> Im bisherigen System teilen alle Web-Seiten eine CSS-
>> Regelsammlung (ein stylesheet), die "stycona" heißt.

>
> Ich fand die Idee, mehrere Stilregelsammlungen im Gebrauch zu
> haben, zunächst überraschend.

Das ist aber durchaus üblich. Fast alle größeren Websites haben mehrere
CSS-Quellen eingebunden. Nicht selten auch CSS-Frameworks wie Bootstrap
oder Sammlungen wie Font Awesome.

> Allerdings denke ich jetzt darüber nach, wie ein Anwender des
> Systems eine neue Auszeichnung hinzufügen könnte. Dafür müßte er
> ja auch sagen, wie die mit CSS formatiert werden soll, und das
> System müßte daraus eine Stilregelsammlung generieren.
[...]

Kann es sein, dass Du versuchst, das Rad neu zu erfinden?

Schau Dir mal an, wie existierende Content Management Systeme und
Auszeichnungssprachen arbeiten.