Bottle: Micro Web Framework

[tabellar]

Hallo zusammen,

zuerst möchte ich mich bei defnull und denen, die dazu
beigetragen haben, für "Bottle" danken. Seit einiger Zeit
habe ich ein paart Test-WebApps mit Bottle am laufen und
ich muss nun in einem ersten Fazit sagen, dass ich noch nie
so schnell meine Ideen in eine (Web-)Applikation umsetzen
konnte.

Ich bin nun an einem Punkt angelangt, wo es darum geht,
die Anwendung - und damit auch Bottle - produktiv einzusetzen.
Als erste Erweiterung zu Bottle habe ich CherryPy 3.2.0 ins
Boot geholt und bin ebenfalls sehr zufrieden. FAPS, gevent
oder vielleicht lighttpd, nginx tc. wären dann ev. die nächsten
Optionen vorne dran.

Nun meine Frage: Gibt es hier im Forum Leute, die Bottle
in "ernsthaften" - ich meine damit "geschäftsfähigen" - Umgebungen
im Einsatz haben? Letztendlich geht es darum, ob z.B. ein
Bottle/CherryPy-Setup mit diversen Erweiterungen (beaker etc.)
gegenüber den "gestandenen" Frameworks wie z.B. Pyramid
konkurrieren kann.

Über Antworten würde ich mich sehr freuen
Tabellar

[Hyperion]

Inwiefern meinst Du denn "konkurrieren"? Bezüglich Speed? Sicherheit? Wartbarkeit? Ich denke, Du musst die Kriterien mal deutlicher machen.

Iirc haben einige Leute schon Anwendungen auf Webspaces laufen... gab mal so nen Flugzeitberechner. Sind auf der Bottle-Seite keine verlinkt?

[tabellar]

Inwiefern meinst Du denn "konkurrieren"? Bezüglich Speed? Sicherheit? Wartbarkeit? Ich denke, Du musst die Kriterien mal deutlicher machen...

Hm, gute Frage. Fangen wir mal mit dem Einfachen an:

- Wartbarkeit: Ich denke, da ist Bottle als one-file-show unschlagbar (Standard-Lib => Linux, Windows, etc., kein Problem). Ausserdem
ist weniger Code immer besser zum Warten (und Erweitern) als viel Code.

- Speed? In der Mittelschicht ist Bottle mit seinen Hauptfunktionen als "URL-Router" und die Verwendung von SimpleTemplate
für mein Empfinden recht schnell und stabil. Wenn es um den WSGI-Server geht, der bei den anderen "grossen Frameworks"
ja auch hin und wieder ausgetauscht wird, kommt es wahrscheinlich mehr auf das Setup und letztendlich die Hardware an.
Klar ist auch, dass die "Bremsen" letztendlich immer die einzelnen durchgerouteten Funktionen und Datenbanken dahinter sind.
Also, um wirklich den Speed zu messen und vergleichen zu können, müsste man die Frameworks bzgl. des Routings an die
Requesthandler vergleichen.

- Sicherheit? Was heisst hier Sicherheit? Die Verwendung von zusätztlichen Security-Modulen wie z.B. Beaker, die dann z.B. in
den "grossen" Frameworks integriert sind. RBAC-Module, die den Zugriff auf irgendwelche dahinterliegenden Objekt- oder Filesysteme
handeln? Bugfreiheit des Routings? Sicherheitsschalter gegenüber Angriffen von Aussen, was aber meistens der jeweilige WSGI-Server
regelt... Ich tu mich schwer hier die Messgrösse "Sicherheit" zu definieren, sprich zu definieren, wie "Sicherheit" gemessen werden
kann. Ein - vielleicht auch etwas hinkender Vergleich - Zope gilt als sicher, aber ist es auch wartbar? Ist es schnell?

... Iirc haben einige Leute schon Anwendungen auf Webspaces laufen... gab mal so nen Flugzeitberechner. Sind auf der Bottle-Seite keine verlinkt?

Da muss ich vielleicht nochmals stöbern...

Prinzipiell geht es mir darum, dass einfache Lösungen meist die besseren Lösungen sind. Das habe ich auch mit Bottle erlebt.
Es stellt sich jetzt tatsächlich die Frage, welchen Mehrwert die "schwerfälligen" Frameworks - und das sind sie nun mal (Wartbarkeit,
Austausch, Deployment, etc. - letztendlich dem Anwender und Coder liefern. Wir leben nunmal in einer sehr schnelllebigen Zeit - und
die Zeit im Web geht wahrscheinlich noch etwas schneller - und ich brauche in diesem Zusammenhang einfache, robuste und
schnell anpassbare und erweiterbare WebApps ...

Tabellar

[uKev]

Die großen/umfangreichen Frameworks (z.B. Django) bieten vor allem eines: Mehr Umfang, d.h. primär einfach viel mehr Funktionen.
Spontan fällt mir da ein: Benutzer-Modell, Datenbank-Modell (ORM), Form-Handling/Generierung (u.A. aus Datenbank-Modell), Pages-Generierung (für Schritt-für-Schritt Assistenten), automatischer CSRF-Schutz durch das Form-Handling, Internationalisierung, uvm...
Das müsstest du dir mit Bottle alles selber bauen oder soweit möglich aus anderen Frameworks zusammen suchen. Falls du es brauchst.

In Sachen Speed und Einfachheit (dadurch auch Wartbarkeit/Einarbeitungszeit) können die Großen Bottle in keinsterweise das Wasser reichen.
Ich benutze Bottle z.B. seit ziemlich genau einem Jahr produktiv auf der Google App Engine. Dort hat man sowieso eine eigene Form von Datenbank und auch die meisten anderen Dinge sind dort etwas anders. Deswegen kam mir da Bottle sehr gelegen. Alle Features, die es mitbringt, kann ich prima nutzen und den Rest habe ich mir selbst gebaut. Formulare habe ich kaum gebraucht, Internationalisierung gar nicht, Benutzer bekommt man bereits durch die App Engine. Perfekt. Warum unnötig Ballast mitschleppen? Ich habe es keine Sekunde bereut und habe seitdem Bottle bei 7 anderen Projekten (teilweise private kleine) eingesetzt. Es eignet sich auch wunderbar um Web-APIs zu realisieren. Wenn andere gestandene Software-Entwickler beteiligt waren, hört man auch schon das eine oder andere mal etwas in der Richtung: "wow, das ging jetzt aber fix".

In Sachen Stabilität/Wartbarkeit kann ich Marcel nur hoch loben, der sich immer extrem angestrengt hat, die Bottle-API möglichst stabil zu halten. An Anpassungen, die ich wegen neuen Features/API Änderungen durchgeführt habe, fällt mir spontan nur eine ein: Am Anfang gab es keinen GAE Server Adapter, das musste man selbst machen (3-5 Zeilen). Irgendwann gab es den dann und ich hab darauf umgestellt (1 Zeile). Der Rest, den ich nicht wegen Änderungen bei mir modifiziert habe, läuft noch genauso, wie am ersten Tag. Ich benutze immer die bottle.py Entwicklerversion "raw" aus dem Github-Repo, also nicht die Releases. Bis auf einmal hatte ich auch immer sauber funktionierenden Code. Das eine Mal hatte Marcel etwas "geschlampt" und nicht richtig getestet. Nach dem Vorfall hat er die Testabdeckung extrem erhöht, damit das nicht wieder vorkommt.

Über die Sicherheit hat Marcel selbst einmal etwas ausführlichere Gedanken hier im Forum angestellt. Da musst du mal suchen. Er hat gedanklich durchgespielt, welche Angriffsvektoren durch die Verwendung von Bottle entstehen könnten. Das Resultat war: sehr sehr wenige. Er bietet ja mit Bottle keine Authentifizierung oder Datenbankzugriffe an.
Das heißt nun natürlich nicht, dass alle Bottle-Anwendungen prinzipiell sicher sind, sondern, dass man selbst bei seinem Code auf Sicherheit achten muss (SQL Injection, CSRF...). Genauso ist es auch bei der Geschwindigkeit: Bottle selbst ist so ziemlich die schlankeste Zwischenschicht, die man sich denken kann. Es liegt am eigenen Anwendungscode, ob das Resultat nun schnell oder langsam ist. Die Verwendung von Bottle hat darauf so gut wie keinen Einfluss.

[noisefloor]

Hallo,

Nun meine Frage: Gibt es hier im Forum Leute, die Bottle in "ernsthaften" - ich meine damit "geschäftsfähigen" - Umgebungen im Einsatz haben?

Ja. Ich habe vier Bottle-basierte Apps im Firmen Intranet laufen. Dazu muss ich aber sagen, dass der Anwenderkreis überschaubar ist und die Apps zwar geschäftlich aber nicht "geschäftskritisch" sind. Wegen des Intranets und des bekannten Userkreises muss ich mir auch weniger Gedanken um die Absicherung machen - wobei ich meine Apps schon als "sicher " betrachte.

Alle Bottle Apps werden unter Ubuntu 10.4 über den Apache + mod_wsgi ausgeliefert. Zusätzlich ist noch SQLAlchemy (mit MySQL DB), WTForms, ReportLab und CouchDB (via python-couchdb) im Einsatz. Klappt alles einwandfrei.

Gruß, noisefloor

[tabellar]

Danke für die Antworten!

...Ich benutze Bottle z.B. seit ziemlich genau einem Jahr produktiv
auf der Google App Engine. Dort hat man sowieso eine eigene Form von Datenbank und
auch die meisten anderen Dinge sind dort etwas anders. Deswegen kam mir da Bottle
sehr gelegen. Alle Features, die es mitbringt, kann ich prima nutzen und den Rest
habe ich mir selbst gebaut. Formulare habe ich kaum gebraucht, Internationalisierung
gar nicht, Benutzer bekommt man bereits durch die App Engine. Perfekt. Warum unnötig
Ballast mitschleppen?

Du sprichst mir aus der Seele. Bei meiner App ist auch alles ab dem "Login-Request-Handler"
selbst gebaut. Ich hatte viele Teilprogramme, die ich jetzt "einfach" hinter das
Bottle-URL-Routing setzten konnte .

Ja. Ich habe vier Bottle-basierte Apps im Firmen Intranet laufen.
Dazu muss ich aber sagen, dass der Anwenderkreis überschaubar ist und die Apps zwar
geschäftlich aber nicht "geschäftskritisch" sind. Wegen des Intranets und des bekannten
Userkreises muss ich mir auch weniger Gedanken um die Absicherung machen - wobei ich
meine Apps schon als "sicher " betrachte. Alle Bottle Apps werden unter Ubuntu 10.4
über den Apache + mod_wsgi ausgeliefert. Zusätzlich ist noch SQLAlchemy (mit MySQL DB),
WTForms, ReportLab und CouchDB (via python-couchdb) im Einsatz. Klappt alles
einwandfrei.

Zuerst habe ich auf Win XP angefangen zu entwickeln. Dabei kamen als Datenbanken
zuerst SQLite, PostgeSQL, Shelve und dann die ZODB zum Einsatz. Berichte werden
mit ReportLab erstellt. Bei den Nutzfunktionen kam dann noch NetworkX zum Einsatz.
Authentifizierung, SessionHandling, Benutzermanagement, RBAC/ACL und MenuControl
ist alles Eigenbau. Als WSGI-Server kam CherryPy zum Einsatz. Hab dann die WebApp
mehr oder weniger auf einen Xubuntu Rechner 11.04, bei dem via Paketmanagemnt
die benötigten Module schnell installiert waren, via USB-Stick "geclont" und
lief nach dem Starten auf Anhieb und war im Intranet verfügbar. Das spielte sich
innerhalb weniger Minuten ab.

Das hört sich alles sehr, sehr gut an! Meine WebApp - und damit Bottle - geht
jetzt damit in Richtung "geschäftkritisch". Da ich noch viele Funktionsmodule implementieren
muss, ist Bottle und die damit verbunden Entwicklungsgeschwindigkeit, von der
wir hier ja noch gar nicht sprachen , für mich ideal.

Grüsse
Tabellar

PS:
Vielleicht gibt's ja noch mehr Anwenderstimmen hier vom Forum.

[snafu]

Welchen Grund hat es eigentlich, dass `bottle.Bottle()`-Exemplare zwar einen `@route`-Dekorator haben, jedoch ein `app.run()` nicht möglich ist? Wurde das bisher einfach nicht bedacht oder entstünden dadurch irgendwelche anderen Nachteile? Ich finde es halt komisch, dass die Doku (Tutorial) von einer "objektorientierten Alternative" spricht, aber man am Ende trotzdem das Applikationsobjekt an die globale `run()`-Funktion übergeben muss.

[Defnull]

Welchen Grund hat es eigentlich, dass `bottle.Bottle()`-Exemplare zwar einen `@route`-Dekorator haben, jedoch ein `app.run()` nicht möglich ist? Wurde das bisher einfach nicht bedacht oder entstünden dadurch irgendwelche anderen Nachteile?

Das ist sowohl möglich als auch sinnvoll, steht auch schon ne Weile auf meiner ToDo Liste, aber andere Baustellen waren bisher immer wichtiger (oder spaßiger zu implementieren)

[Defnull]

Bottle 0.10 is da Es gibt ne menge neues, am bessten schaut ihr euch die Zusammenfassung im Change-log an.

Changelog: http://bottlepy.org/docs/0.10/changelog ... lease-0-10
PyPi link: http://pypi.python.org/pypi/bottle/0.10.1

[snafu]

Noch ein weiterer Vorschlag in Bezug auf `run()`: Man könnte dort direkt eine Option für's Debugging einbauen, um dem Benutzer ggf eine Zeile Code zu ersparen. `debug` sollte IMO als Default-Wert auf `False` stehen. Der Wert wird dann stumpf an `bottle.debug()` weitergeleitet.

Ich hoffe, es ist okay, Verbesserungsvorschläge auch hier zu posten und nicht das offizielle Ticketsystem zu nutzen.

[Defnull]

Klar ist das ok Und eine gute Idee auch noch.

[lackschuh]

Hallo

Kurze Ja/Nein Frage in Bezug auf dieses Thema:

ist Bottle überhaupt geeignet, für eine Webpage, welche mehrere Seiten und Unterseiten hat, JS und jQuery einsetzt und ein Kontaktformular?
(Oder wäre etwas größeres wie Django vorteilhafter?)

[deets]

Dafuer ist es schon geeignet. Programmieren koennen muss man aber immer noch - ich denke, *da* haperts eher. Kann natuerlich sein, das Django schon so viel Abstraktionen mitbringt, dass man da mit weniger Kenntnissen aehnlich weit kommt.

[/me]

ist Bottle überhaupt geeignet, für eine Webpage, welche mehrere Seiten und Unterseiten hat, JS und jQuery einsetzt und ein Kontaktformular?
(Oder wäre etwas größeres wie Django vorteilhafter?)

Der Einsatz von JavaScript ist kein Problem. JavaScript sendet ja vom Client aus im Endeffekt auch nur Requests die vom Framework angenommen und delegiert werden. Prinzipiell ist das nichts wirklich anderes als das "normale" Aufrufen einer Webseite.

[lackschuh]

Hallo

Kurze Frage bezüglich active link (css): ich habe ein Menü. Die einzelnen Kategorien stehen in einer Liste

Code: Alles auswählen

menu = [

['home'],
['kontakt'],
['blabla']
]

Im Template wird das Menü wie folgt eingebunden

Code: Alles auswählen

<div class="menu_nav">
        <ul>
          %for row in menu:
          <li> <a href="{{row[0]}}">{{row[0]}}</a> </li>
          %end
        </ul>
      </div>

Und in der .css

Code: Alles auswählen

.menu_nav ul a.activ_pfad {
	text-decoration:none;
	color:#990000;
}

Leider wird aber im Menü nicht angezeigt, welcher Link gerade aktiv ist.

Hat jemand eine Idee?

[deets]

1. das ist eine HTML-Frage
2. das hat doch nix mit bottle zu tun, mach dafuer wahlweise einen eigenen Thread auf, oder frag in einem web-spezifischeren Forum nach.

[lackschuh]

1. das ist eine HTML-Frage

Das hat doch nichts mit HTML zu tun. Das ist eine Python/Bottle-Frage, in der geklärt werden muss, wie ich den aktiven Pfad definiere und ihm eine CSS-Klasse mit auf die Reise gebe.

[Hyperion]

Na Du musst Deine Menüstruktur irgend wie so erweitern, dass neben dem Pfad auch der aktive Menüpunkt eingetragen wird - oder Du übergibst diesen getrennt.

Dann kannst Du im Template in der Schleife eine `if`-Abfrage einbauen und wenn der aktuell gerenderte Link mit dem aktiven übereinstimmt, dann änderst Du entsprechend die CSS-Klasse. Ich kenne die Template-Engine von Bottle jetzt nicht näher, aber so in der Art ginge das sicher.

Wenn man die Struktur geeignet anpasst, so kann man wohl auch auf das `if` verzichten, also etwa in der Art:

Code: Alles auswählen

menu = [
    ('home', 'menu')
    ('kontakt', 'active'),
    ('blabla', 'menu'),
]

Dabei steht zuerst der Pfad und danach die Klasse.

[seishin]

Moin,

folgende Problematik:
Ich ziehe aus einer API ein image und reiche dieses an ein template weiter um es dort mit html <img src... anzuzeigen.
So nu ist es ja so das BottlePy das alles cachet... demnach wird das Bild nicht angezeigt.

Ist es möglich für diesen einen Teil der Anwendung den cache zu deaktivieren?

Denn ich habe wenig Lust die Dateien lokal zu speichern... und dann als static einzubinden...

Ich hoffe ich habe mich verständlich ausgedrückt...

Ergänzend: Wenn man die Bilder (der Link ist ja da) in einem anderen Tab öffnet, und dann die Seite wo es eigentlich sein sollte neu aufruft ist das Bild da... was ich jedoch noch nicht getestet habe ist dieses verhalten auf unterschiedlichen clients...



Gruß und danke!

[BlackJack]

@seishin: Ich denke Du interpretierst da etwas falsch. Bottle cachet nicht alles, sondern nur Templates und zwar *unausgefüllte*. Sonst wäre es echt schwierig dynamische Webseiten damit zu realisieren.

Was heisst denn Du reichst das Bild an ein Template weiter? Direkt im Template kannst Du ein Bild nur als „data”-URL einbauen. Tust Du das? Ansonsten musst Du bei <img src=…> eine URL angeben unter der das Bild vom Browser angefordert werden kann *nachdem* er das ausgefüllte Template bekommen hat. Das ist dann eine weitere, separate Anfrage vom Browser.