Seite 1 von 1

Python und Webseiten

Verfasst: Mittwoch 18. Oktober 2006, 23:52
von Falko
Hallo zusammen,
ich habe schon mich durch das Forum gewühlt aber eine Frage bleibt mir unbeantwortet.

Wenn ich mit Python etwas komplexere Forumlar Datenbank / Eingabe Ausgabe geschichten mache.

Ähnlich wie vieleicht ein Kleinanzeigenmarkt, müssen die "design" Datein wie. wenn ich in PHP proggen würde, ein .php tragen ?

Also Index.py? und wenn ja wie lege ich den das Designtemplate in einer Phyton struktur überhaupt fest?

Bin da momentan ein wenig wirr, mir ist klar wie es bei html geht, mir ist klar wie es bei php geht, nur was mache ich wenn in python programmiert wird, und ich in das webseiten template daten lade, oder per forumlar eingeben lasse.

Wäre nett wenn mich da jemand aufklären könnte.

Vielen Dank Viele Grüße



Ps. Ich will nicht die komplette webseite oder das komplette design mit phyton generieren, lediglich die ein und ausgabe felder (formulare ) gibts da nicht irgendwie aehnlich wie bei php <php ?> das ding noch .php enden lassen und ab gehts?

Re: Python und Webseiten

Verfasst: Donnerstag 19. Oktober 2006, 08:06
von gerold
Falko hat geschrieben:Wäre nett wenn mich da jemand aufklären könnte.
Hi Falko!

Willkommen im Python-Forum!

Die Antwort wird dir nicht gefallen:

- http://www.python-forum.de/topic-7063.html
- [wiki]Python im Web[/wiki]
- http://www.python-forum.de/topic-5303.html

CGI: Klein, fein, aber für große Projekte ungeeignet.
PSE: Klein, so ähnlich wie PHP, aber mit dem Vorteil, dass Vorlagen und Logik voneinander getrennt sind.

Oder eines der vielen Frameworks wie z.B. Zope (http://www.python-forum.de/topic-7097.html).

mfg
Gerold
:-)

Verfasst: Donnerstag 19. Oktober 2006, 11:52
von Falko
Danke für deine Antwort,

also verstehe ich das richtig das es keinenfalls so leicht ist wie zb bei php eine html seite zu nehmen php aufrufe einzubetten und sie .php zu nennen?

Wenn ich das richtig gelesen habe ist es sogar sehr schwer ein "fertiges" design so umzubauen das es mit PSE oder CGI funktiert.

Oder bin ich irgendwie aufem falschen "Dampfer".

Ich habe auch mal nach Webseiten design beispielen gesucht aber keine gefunden.

Ich hab so das laue gefühl das ich es immernoch nicht verstanden habe.

Den ein komplex aufgebautes Design ist doch so verworren wie soll ich das den da reingestopfed kriegen..


Grüße

Verfasst: Donnerstag 19. Oktober 2006, 12:03
von Whitie
Hi Falko,
ich setze PSE erfolgreich ein. Es muss nur PSE auf dem Server installiert sein, dann funktioniert es ähnlich wie PHP.

Aus den Examples der PSE Seite:

Code: Alles auswählen

<html>

  <head>
    <title>Sample PSE Application</title>
  </head>

  <body>
    <? print "Hello, world!" ?>
  </body>

</html>
Bei mehr als einer Python-Anweisung ist allerdings trotz PSE auf die Einrückung zu achten.
Ganz so einfach wie PHP ist es also nicht, aber ich hab mich schnell dran gewöhnt und es kommt mir "sauberer" vor.

Gruß, Whitie

Verfasst: Donnerstag 19. Oktober 2006, 12:45
von jens
Falko hat geschrieben:Wenn ich das richtig gelesen habe ist es sogar sehr schwer ein "fertiges" design so umzubauen das es mit PSE oder CGI funktiert.

Oder bin ich irgendwie aufem falschen "Dampfer".
Ich würde sagen ja :)

Naja, es ist wohl kein Problem CGI-Skripte in eine Webseite zu integrieren. Das geht gut, wenn du nur einen counter einbauen willst... Wenn du aber eine komplexere Seite aufbauen willst, kommst du wohl nicht um ein CMS herrum. Statische Webseiten pflegen ist sehr aufwendig. Ich hab meine Homepages Jahrelang nur mit statischen Seiten ralisiert. Aber irgendwann macht das einfach keinen Spass mehr, sondern einfach nur viel Arbeit :)

Deswegen hab auch ich meine statischen Seiten in einem CMS "gewandelt". Da es kein kleines CMS in Python gab, hab ich PyLucid-CMS programmiert :) Vielleicht ist es was für dich ;)

Verfasst: Donnerstag 19. Oktober 2006, 13:21
von Leonidas
Whitie hat geschrieben:Bei mehr als einer Python-Anweisung ist allerdings trotz PSE auf die Einrückung zu achten.
Ganz so einfach wie PHP ist es also nicht, aber ich hab mich schnell dran gewöhnt und es kommt mir "sauberer" vor.
Mir kommen so Sachen wie PSE oder das warscheinlich populärere Spyce keineswegs mehr sauber vor - nicht nachdem ich ein richtiges Framework mit einem richtigen Templating-System ausprobiert habe. Das ist zwar komplexer, aber wesentlich sauberer.
jens hat geschrieben:Naja, es ist wohl kein Problem CGI-Skripte in eine Webseite zu integrieren. Das geht gut, wenn du nur einen counter einbauen willst... Wenn du aber eine komplexere Seite aufbauen willst, kommst du wohl nicht um ein CMS herrum. Statische Webseiten pflegen ist sehr aufwendig. Ich hab meine Homepages Jahrelang nur mit statischen Seiten ralisiert. Aber irgendwann macht das einfach keinen Spass mehr, sondern einfach nur viel Arbeit :)
Man kann auch statische ReST-Dateien pflegen und diese automatisch rendern lassen, so wie es Django macht und so wie es auch Pocoo mit Sphinx macht. Python.org macht das gleiche, jedoch haben die da was ziemlich gegen die Wand gefahren, so dass das nicht so toll ist wie gedacht.
jens hat geschrieben:Deswegen hab auch ich meine statischen Seiten in einem CMS "gewandelt"
Ich nutze momentan ein Wiki, was eigentlich auch ausreicht. Nur bin ich inzwischen so faul geworden, dass ich den Inhalt nicht mehr pflege.
jens hat geschrieben:Da es kein kleines CMS in Python gab, hab ich PyLucid-CMS programmiert :) Vielleicht ist es was für dich ;)
Jetzt gibt es ein kleines CMS: Skeletonz. Von den kleinen CMS finde ich auch Radiant interessant, ist aber nicht in Python geschrieben.

Verfasst: Donnerstag 19. Oktober 2006, 13:23
von gerold
Falko hat geschrieben:also verstehe ich das richtig das es keinenfalls so leicht ist wie zb bei php eine html seite zu nehmen php aufrufe einzubetten und sie .php zu nennen?
Hi Falko!

Die meisten Provider setzen auf PHP. Apache, MySQL und PHP. Das ist derzeit der Standard der vorhält. Die Provider müssten einfach nur zusätzlich PSE installieren. Schon wäre es so einfach wie mit PHP. Einfach eine Datei mit der Endung "*.pt" per FTP hochladen -- fertig!

Allerdings sind die meisten Provider noch nicht auf diesen Zug aufgesprungen, da sich viele einfach mit PHP zufrieden geben. -- Angebot und Nachfrage!

Auch wenn PSE nicht unbedingt mein Geschmack ist, -- von Active Server Pages und PHP bin ich schon längst geheilt -- so würde PSE auf den Internetservern, Python um ein Vielfaches bekannter machen.

Was Python fehlt, ist so etwas einfaches zum Entwickeln von Internetseiten wie es PHP schon längst ist. PSE wäre so etwas. Einfach eine HTML-Seite mit der Endung "*.tp" versehen und schon wird diese von PSE interpretiert.
Die PSE-Seiten werden einfach unter die statischen HTML-Seiten gemischt und per FTP zum Server hochgeladen. Schon funktiniert alles. -- Genau so wie bei PHP. Man mag über PHP schimpfen wie man möchte, aber eines kann man PHP nicht nehmen: Es ist sehr einfach, mit PHP zu beginnen. Das ist es was uns bei Python noch fehlt. Wie ich bereits schrieb, glaube ich, dass PSE das Zeug dazu hätte, Python vielen vielen Menschen/Webdesignern näher zu bringen.

Nur wir Pythonistas sind so hochnäsig, dass wir immer nach dem perfekten Framework suchen und da wir es nicht finden, programmiert jeder zweite sich sein eigenes Framework.

So entstehen unzählige Python-Webframeworks, die aber alle das Wichtigste vergessen. Meistens setzt sich nicht das Beste, sondern das Einfachste durch. -- Auch wenn man sich damit Nachteile einhandelt. Wie z.B. eine unsaubere Trennung zwischen Darstellung und Programmlogik.

Hiermit fordere ich jeden Internetprovider auf, PSE (http://nick.borko.org/pse/) auszuprobieren und auf den Servern zu installieren. Alle Frameworks, bei denen man eine Seitenvorlage nicht einfach per FTP hochladen und benutzen kann, werden sich nicht durchsetzen können. Bis es bei TurboGears, Django, Zope und Co. so weit ist, dass die Entwicklung so einfach wie bei PHP ist, werden wir mit PSE sicher tausenden Leuten Python näher bringen können.

mfg
Gerold
:-)

Verfasst: Donnerstag 19. Oktober 2006, 13:32
von Leonidas
gerold hat geschrieben:Hiermit fordere ich jeden Internetprovider auf, PSE (http://nick.borko.org/pse/) auszuprobieren und auf den Servern zu installieren.
Was hat PSE für Vorteile gegenüber Spyce? Bei Spyce ist ja seit version 2.0 die Entwicklungsgeschwindigkeit massiv erhöht worden und es hat genug Verbreitung gehabt, udass die iX einen Artikel dazu geschrieben hat.
gerold hat geschrieben:Alle Frameworks, bei denen man eine Seitenvorlage nicht einfach per FTP hochladen und benutzen kann, werden sich nicht durchsetzen können.
Das würde ich nicht so generell Sagen: Ruby on Rails funktioniert nicht so und trotzdem wird es immer populärer und verdrängt andere Programmiersprachen und Frameworks.

Edit: Typos korrigiert.

Verfasst: Donnerstag 19. Oktober 2006, 13:32
von jens
gerold hat geschrieben:Die meisten Provider setzen auf PHP. Apache, MySQL und PHP. Das ist derzeit der Standard der vorhält.
Da hast du wohl recht :( Aber genau deswegen auch die Seite [wiki]Python Webspace[/wiki]damit man nicht lange Suchen muß :)

Ich denke allerdings nicht, das PSE so dolle ist. Generell die Mischung von HTML und Sourcecode ist mies... Das ist IMHO das selbe wie keine Trennung von HTML und CSS... Macht auch kaum einer mehr...

Von PyLucid hält aber hier keiner was :evil:

Verfasst: Donnerstag 19. Oktober 2006, 13:49
von Falko
Wow ich dachte euch erstmal ihr überschlagt euch ja förmlich, man merkt ihr mögt "eure" programmiersprache ( isses eine oder faellts unter die scriptsprachen )

Ich sehe schon es gibt hunderte von Möglichkeiten vieleicht sollte ich 2 3 Sätze darüber verlieren warum ich versuche mich mit der Materie zu beschäftigen.


Ich habe das Design für ein Projekt entwickelt, im großen und ganzen ein "anzeigemarkt" mit suche und biete... das script was dahinter laufen wird , wird von 1-2 Phyton Programmieren entwickelt. Ich selber kenne mich mit Phyton gar nicht aus, was nicht weiter schlimm is ich versuch ja gerade etwas darüber rauszufinden ;-)

Nun haben einige Leute hier einige vorschläge gemacht.
Vorneweg ich kann einsetzen was auf einem Debian Server läuft, ich bin also nicht an irgendwelche Vorgaben gebunden.

Fakt ist, Irgendwie muss ich das Design nun umsetzen. Nun ist eben die Frage hmm CMS System, Design in CMS system anpassen und den Programmierer dann im CMS system programieren lassen ?

Die Html und <? ?> eingebettet variante?

Es hat vom Formular Umfang her einen Umfang wie sagen wir mal mobile.de Also schon von dem was phyton nacher machen wird, ein stolzes Stück Arbeit.

Vieleicht gibts ja noch paar Tips für mich. Vielen Dank schonmal

Viele Grüße
Falko


PS. Vieleicht kennt ja jemand einen Designer der sich damit auskennt , komplette Designs in ein phyton CMS zu integrieren sodas die programmer im cms proggen können ( sofern das möglich ist ? riesige formulare die auf seiten angezeigt werden muessen im cms zu proggen ? ) Oder Designer die große projekte schon umgesetzt haben wo viel phyton arbeit von phyton verrichtet wird =)

Verfasst: Donnerstag 19. Oktober 2006, 13:54
von jens
Also mit PyLucid kannst du IMHO fast alles machen.

Beispiele:
http://www.pylucid.org
http://www.jensdiemer.de
http://www.htfx.de
http://www.mactricks.de

Verfasst: Donnerstag 19. Oktober 2006, 14:07
von gerold
Leonidas hat geschrieben:Was hat PSE für orteile gegenüber SPyce?
[...]
Ruby on Rails funktioniert nicht so und trotzdem wird es immer populärer und verdrängt andere Programmiersprachen und Frameworks.
Hi Leonidas!

PSE-Vorlagen sehen in meinen Augen schöner aus als SPyce-Vorlagen. Spyce hat mich sofort abgeschreckt, als ich es zum ersten Mal sah. Das ist der einzige Grund, weshalb ich zu PSE und nicht zu SPyce rate. Quellcode muss schön aussehen. Sonst macht mir Programmieren keinen Spaß.

Ich habe Websites mit PHP programmiert. Dann bin ich zu Active Server Pages (VB-Script) gewechselt. Nach einer langen Zeit mit ASP bin ich zu ASP.NET (VB.NET) konvertiert. Seit ich mich für Python interessiere, habe ich mich nach etwas umgesehen, was es mir ermöglicht, auch Websites mit Python zu programmieren. Man kann also nicht sagen, dass ich nicht das Wissen dazu hätte, um die einzelnen "Möglichkeiten" miteinander zu vergleichen. Dass ich dabei dann bei Zope hängen geblieben bin, hängt auch von der Tatsache ab, dass alle anderen, mir damals bekannten, Frameworks es nicht gestatteten, einfache Sachen auch einfach zu machen.

Wenn ich davon lese, dass ich nicht ohne weiteres eine statische HTML-Seite mit in das System (Webframework) einbinden kann. Oder dass eine Vorlage nicht einfach alleinstehend, also ohne sie irgendwo eintragen zu müssen, oder in den Quellcode einbinden zu müssen, existieren kann, dann weiß ich was bei den meisten Frameworks falsch gemacht wurde.

PHP hat sich durchgesetzt weil es so einfach ist, eine statische HTML-Seite in eine dynamische PHP-Seite umzuwandeln. Oft will man ja nur ein paar Daten aus einer Datenbank auslesen und anzeigen. Es kann doch nicht sein, dass man deshalb ein Programm schreiben muss, welches eine HTML-Seite imitiert. ``def index(request, ...): return "Hallo Welt"``
Warum kann nicht einfach eine Textdatei in einem Ordner stehen. Diese Textdatei hat eine Endung, die dem Apachen sagt, dass diese von einem Vorlagensystem interpretiert wird und dann erst angezeigt wird. Und wenn ich in diese Textdatei nur ``Hallo Welt`` rein schreibe, dann soll einfach nur ``Hallo Welt`` angezeigt werden. Das ist einfach! Das ist PSE!

Ich bleibe bei Zope, da ich gelernt habe wie man damit arbeitet. Ich schätze TAL und die Acquisition (Vererbung). Aber jedem, der einfach mal anfangen möchte Python in der Webprogrammierung zu verwenden, muss ich zu PSE raten.
Um sich in PSE einzuarbeiten braucht man Stunden. Um sich in die anderen Python-Webframeworks einzuarbeiten braucht man Tage und Wochen.

Das lass ich einfach mal so stehen...

lg
Gerold
:-)

Verfasst: Donnerstag 19. Oktober 2006, 14:13
von Leonidas
Falko hat geschrieben:Wow ich dachte euch erstmal ihr überschlagt euch ja förmlich, man merkt ihr mögt "eure" programmiersprache ( isses eine oder faellts unter die scriptsprachen )
Python ist eine Programmiersprache. Als solche kann sie auch als Skriptsprache verwendet werden, aber das Skript-Sprache-sein ist an keine besonderen Bedingungen geknöpft. So kann man C auch als Skriptsprache verwenden.
Falko hat geschrieben:Ich habe das Design für ein Projekt entwickelt, im großen und ganzen ein "anzeigemarkt" mit suche und biete... das script was dahinter laufen wird , wird von 1-2 Phyton Programmieren entwickelt. Ich selber kenne mich mit Phyton gar nicht aus, was nicht weiter schlimm is ich versuch ja gerade etwas darüber rauszufinden ;-)
Als Designer wird dir sicher ein gutes Templating-System sehr zur Hand gehen. So kannst du das Design machen und die Programmierer machen sich an die Programmierung.
Falko hat geschrieben:Nun haben einige Leute hier einige vorschläge gemacht.
Vorneweg ich kann einsetzen was auf einem Debian Server läuft, ich bin also nicht an irgendwelche Vorgaben gebunden.
Ah, sowas ist immer super. Ich habe mir erst vorgestern Python 2.5 auf Sarge gebackportet um meine Django-Webseite zu aktualisieren :)
Falko hat geschrieben:Fakt ist, Irgendwie muss ich das Design nun umsetzen. Nun ist eben die Frage hmm CMS System, Design in CMS system anpassen und den Programmierer dann im CMS system programieren lassen ?
Ich glaube, dazu solltest du auch die Programmierer befragen. Du kannst ihnen anbieten sich Skeletonz anzusehen um zu gucken ob sie damit auskommen.
Falko hat geschrieben:Die Html und <? ?> eingebettet variante?
Davon würde ich abraten. Sogar für PHP gibt es Frameworks wie Seagull und Co ebenso wie etliche Templating-Systeme.
Falko hat geschrieben:Es hat vom Formular Umfang her einen Umfang wie sagen wir mal mobile.de Also schon von dem was phyton nacher machen wird, ein stolzes Stück Arbeit.
Dann lohnt es sich ja vielleicht das ganze gleich mal etwas größer aufzuziehen. Mit TurboGears, Django oder Pylons hast du immer etwas Platz nach oben.

Verfasst: Donnerstag 19. Oktober 2006, 14:20
von jens
Leonidas hat geschrieben:Jetzt gibt es ein kleines CMS: Skeletonz.
btw. Skeletonz kannst du aber IMHO nicht auf einfachem Shared-WebSpace benutzten. Es startet einen eigenen WebServer. Siehe:
http://orangoo.com/skeletonz/User%20gui ... d%20guide/
http://orangoo.com/skeletonz/User%20gui ... %20Apache/

Verfasst: Donnerstag 19. Oktober 2006, 14:52
von Leonidas
gerold hat geschrieben:PSE-Vorlagen sehen in meinen Augen schöner aus als SPyce-Vorlagen. Spyce hat mich sofort abgeschreckt, als ich es zum ersten Mal sah. Das ist der einzige Grund, weshalb ich zu PSE und nicht zu SPyce rate. Quellcode muss schön aussehen. Sonst macht mir Programmieren keinen Spaß.
Naja, ob ich meinen Code in < ? ?> oder in [[\ ]] das macht keinen großen Unterschied. Außerdem Unterstützt Spyce auch ASP/JSP-Style-Tags.
gerold hat geschrieben:Man kann also nicht sagen, dass ich nicht das Wissen dazu hätte, um die einzelnen "Möglichkeiten" miteinander zu vergleichen.
Das habe ich nie angezweifelt.
gerold hat geschrieben:Dass ich dabei dann bei Zope hängen geblieben bin, hängt auch von der Tatsache ab, dass alle anderen, mir damals bekannten, Frameworks es nicht gestatteten, einfache Sachen auch einfach zu machen.
Ich glaube nicht, dass es damals (ich weiß ja nicht wie lange du schon mit Zope arbeitest, aber auf jeden Fall schon vor dem großen Framework-Hype) so viele besonders tolle Frameworks gab. Subway vielleicht, welches inzwischen von TurboGears komplett ersetzt wurde und Webware, dessen WSGI-Variante WSGIKit wurde und vollständig in Paste aufgegangen ist. Beide alten Frameworks sind nun in Bedeutungslosigkeit verschwunden.
gerold hat geschrieben:Wenn ich davon lese, dass ich nicht ohne weiteres eine statische HTML-Seite mit in das System (Webframework) einbinden kann. Oder dass eine Vorlage nicht einfach alleinstehend, also ohne sie irgendwo eintragen zu müssen, oder in den Quellcode einbinden zu müssen, existieren kann, dann weiß ich was bei den meisten Frameworks falsch gemacht wurde.
Dann kann ich dich beruhigen, dass Django es richtig gemacht hat. Das was du beschriebst kann man ohne besonders großen Aufwand mit einer Middleware implementiere. In der Tat gibt es bereits jetzt schon etwas sehr ähnliches, die sogenannten Flatpages. Jedoch sind diese in der Datenbank gespeichert und können auch noch automatisch durch ein Template geschickt werden.
gerold hat geschrieben:PHP hat sich durchgesetzt weil es so einfach ist, eine statische HTML-Seite in eine dynamische PHP-Seite umzuwandeln. Oft will man ja nur ein paar Daten aus einer Datenbank auslesen und anzeigen.
Kann ich nachvollziehen. Aber man wenn es geringfügig mehr wird, kann man entweder seinen Code unglaublich verkomplizieren oder man steigt auf Template-Systeme, ORMs, Session-Verwaltungen um. Daher gibt es Frameworks, wo natürlich einfaches einfach sein sollte (da stimme ich dir absolut zu), aber auch komplizierteres nicht zu einer Tortur werden sollte.
gerold hat geschrieben:Warum kann nicht einfach eine Textdatei in einem Ordner stehen. Diese Textdatei hat eine Endung, die dem Apachen sagt, dass diese von einem Vorlagensystem interpretiert wird und dann erst angezeigt wird. Und wenn ich in diese Textdatei nur ``Hallo Welt`` rein schreibe, dann soll einfach nur ``Hallo Welt`` angezeigt werden. Das ist einfach! Das ist PSE!
Das ist ebenso Spyce als auch Karrigell ;)
gerold hat geschrieben:Ich bleibe bei Zope, da ich gelernt habe wie man damit arbeitet. Ich schätze TAL und die Acquisition (Vererbung).
Auch da stimme ich dir zu: ich mag mein Framework auch und würde nur ungerne wieder zurück zu Python-in-HTML.
gerold hat geschrieben:Um sich in PSE einzuarbeiten braucht man Stunden. Um sich in die anderen Python-Webframeworks einzuarbeiten braucht man Tage und Wochen.
Wenn man von PHP kommt, dann bestimmt. Denn da man nichts anderes kennt muss das wohl der Weg sein wie man Dinge löst. Das ist natürlich Quick aber eben meist auch Dirty. Ich gebe auch zu, dass die Einarbeitung in Django und in vermutlich auch in Pylons nicht unbedingt sehr schnell geht. Aber ich denke, dass ein Anfänger mit TurboGears (besonders wegen CherryPy) auf keinen Fall Wochen braucht um brauchbare Ergebnisse zu erzielen.

Verfasst: Donnerstag 19. Oktober 2006, 14:57
von Leonidas
jens hat geschrieben:btw. Skeletonz kannst du aber IMHO nicht auf einfachem Shared-WebSpace benutzten.
Das ist hier aber nicht der Fall, hier steht alles zur Verfügung was man braucht. Und Shared Webspace kann man sowieso in der Pfeife rauchen, bis auch CGI gibts da meist nichts interessanteres. Meine FastCGI-Server brauchen ja auch einen permanent laufenden Python-Prozess, von dem her ist das dann auch egal.
jens hat geschrieben:Es startet einen eigenen WebServer.
Man könnte amix ja mal fragen, ob man AmiWeb nicht irgendwie modifizieren kann.

Verfasst: Freitag 20. Oktober 2006, 08:10
von Leonidas
Leonidas hat geschrieben:
jens hat geschrieben:Es startet einen eigenen WebServer.
Man könnte amix ja mal fragen, ob man AmiWeb nicht irgendwie modifizieren kann.
Gestern haben blackbird und ich mit amix gesprochen und seit Revision 359 lässt sich AmiWeb (welches in etwa Colubrid entspricht) über alle WSGI-Server ansprechen. Somit sollte man nun Skeletonz sowohl standalone laufen lassen können (Paste, CherryPy-Server) als auch über CGI, mod_python, FastCGI, SCGI und AJS in einen bestehenden Webserver einbinden können.
Damit ist das "eigener Webserver"-Argument nun ausgeräumt.