Problem mit Flask-Login und jQuery Mobile

Django, Flask, Bottle, WSGI, CGI…
Antworten
burli
User
Beiträge: 1156
Registriert: Dienstag 9. März 2004, 18:22

Hi, ich habe eine Anwendung mit Flask geschrieben. Ich verwende da Flask-Login. Mit klassischem HTML hat alles funktioniert. Jetzt habe ich die Templates lediglich etwas an jQuery Mobile angepasst, aber dadurch scheint es Probleme mit dem Login zu geben. Speziell mit @fresh_login_required scheint es Probleme zu geben.

Ich habe zum Beispiel eine Profilseite für einen User geschrieben. Ich kann die Seite aufrufen, aber wenn ich die Änderungen speichern will soll die Seite neu authentifiziert werden, aber es funktioniert nicht.

Ich steige noch nicht ganz durch, wie Flask-Login das handelt und wie jQuery da dazwischenfunkt. Kann mir das jemand erklären?
Das schwierigste beim Programmieren ist, sinnvolle Variablen- und Funktionsnamen zu finden :lol:
Jurudoca
User
Beiträge: 23
Registriert: Dienstag 26. Juli 2011, 13:58

hi vielleicht liegt das an ajax, das standartmäßig angeschaltet ist...
mir hat das hier geholfen...einfach in den head des templates einfügen:

Code: Alles auswählen

<script type="text/javascript">
    $(document).bind("mobileinit", function(){
    ajaxEnabled:false;    
    });
    </script> 
vielleicht funktioniert das bei dir auch...

Grüße
Juru
burli
User
Beiträge: 1156
Registriert: Dienstag 9. März 2004, 18:22

Danke, ich probiere es vielleicht mal. Ich bin allerdings gerade am überlegen, auf jQuery Mobile zu verzichten und dafür mit normalem HTML und CSS ein mobiles Interface zu bauen. Auf die Transitions kann ich eigentlich verzichten.
Das schwierigste beim Programmieren ist, sinnvolle Variablen- und Funktionsnamen zu finden :lol:
Jurudoca
User
Beiträge: 23
Registriert: Dienstag 26. Juli 2011, 13:58

ja JQM macht es einem schon schwer wegen diesem ganzen ajax schnick-schnack.
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

burli hat geschrieben:Ich bin allerdings gerade am überlegen, auf jQuery Mobile zu verzichten und dafür mit normalem HTML und CSS ein mobiles Interface zu bauen. Auf die Transitions kann ich eigentlich verzichten.
Die Frage ist ja, was du erreichen willst.

<rant>
Soll es einfach eine kleine Webseite sein, die man gut konsumieren kann, wenn man per Handy darauf zugreift, braucht man kein großes Rahmenwerk sondern nur ein paar media-queries, unterschiedliches CSS und sauber strukturiertes HTML.

JQM verspricht, nicht nur Webseiten, sondern "Apps" bauen zu können, die dank des Ansatzes, den kleinsten gemeinsamen Nenner zu unterstützen, auf einer Vielzahl - auch exotischer - Plattformen laufen. Man bekommt außerdem die meisten vom iPhone geprägten Interaktionsmuster, z.B. die "drill down"-Navigation mit der typischen links-rechts-Transition. In wie weit es sinnvoll ist, die plattformspezifischen Muster anderer Plattformen mit Füßen zu treten (Metro funktioniert so grundsätzlich anders, dass zur Zeit noch alle froh sind, das nicht unterstützen zu müssen) ist ein anderes Thema.

Der Übergang zwischen Website und Webapp ist fließend, daher sind absolute Aussagen schwierig, doch ich finde, mit JQM ist man immer noch mehr auf der Seite der Website und weniger auf der einer "App". Insbesondere, wenn man sich mit nativen Apps unter iOS, Android oder Metro vergleichen will oder muss. Daher würde ich dieses Rahmenwerk empfehlen, wenn man eine Site bauen will, die sich ein bisschen wie eine App anfühlen soll, aber nicht das Geld ausgeben will/kann, native Apps zu bauen.

Ich meine hier native weniger in dem Sinn, dass man sich mit plattformspezifischen Entwicklungswerkzeugen, Programmiersprachen, SDKs und Deployment-Strategien herumschlagen muss, sondern eher in der Art, wie Apps auf diesen Plattformen aussehen und funktionieren.

Gefühlt sind zur Zeit 1/3 alle Android Apps schlechte Ports von iOS, die als native Android-Apps eigentlich anders aussehen und funktionieren würden. Wie vielen Anwendern das egal ist, weiß ich leider nicht, aber ein "ihr seit uns nicht wichtig genug für eine eigenständige App" kommt schon bei mir an. Damit ist und bleibt Android leider selbstverstärkend zweitklassig.

Ein (notwendiges aber wohl nicht hinreichendes) Unterscheidungskriterum zwischen Site und App ist für mich, ob das HTML auf dem Server für jede Seite generiert wird oder ob man einmal HTML über die Leitung schickt und dann nur noch (auf dem Server generierte) Daten austauscht. Letztes ist klar ein Anwendungen-Architektur-Muster und der IMHO bessere Ansatz, der uns aus den 70ern der Großrechner-Terminals zurück in die 80er mit Fat/Rich-Clients katapultiert, wo wir in den 90ern ja schon einmal angekommen waren :)

JQM unterstützt dank Ajax (was ich jetzt im Hinblick auf Apps nicht als "schnick-schnack" bezeichnen würde) diese auch "one page app" genannte Vorgehensweise, zieht es IMHO aber nicht so konsequent durch wie z.B. Backbone und Co. es erfordern.

Solange derartige JavaScript-Client-Rahmenwerke nur einen Pissing-Contest in wer kann's kleiner durchziehen und nicht gewertschätzt wird, wer eigentlich wie viel Arbeit abnimmt, bin ich mir nicht sicher, wo der klare Sieger ist. Es hilft leider auch nicht, dass interaktive Rich-Client-Anwendungen zu bauen, nun einmal schwerer ist, als Webseiten statisch zu generieren, sodass hilfreiche Rahmenwerke hier zwangsläufig komplexer sein müssen.

Doch der nächste Schritt zur App im Browser ist zwangsläufig die Abstraktion von HTML und CSS hinzu JavaScript, wie es z.B. Sencha bietet, das versucht, iOS möglichst gut und Android ein bisschen nachzuahmen. Das Uncanny Valley ist hier nicht weit und eigentlich ist der Vorteil nur noch, JavaScript statt Java und Objective-C beherrschen zu müssen. Das Rahmenwerk, welches zu erlernen die eigentliche Herausforderung ist, ist jetzt auch nicht einfacher zu beherrschen, als UIKit oder das der passende Teil aus dem Android-SDK. OK, es ist schon einfacher, aber dafür läuft man schneller in Bereiche wo's nicht so geht wie man will und muss auch hier 2 Varianten der App bauen, wenn's gefühlt nativ (siehe oben) sein soll. Zudem bietet Sencha keine Antwort auf die Metro-Frage.

Ein Webserver liefert hier aber nicht mehr Seiten sondern nur noch Daten aus. Und das ist IMHO auch gut so, denn es vereinfacht die Programmierung der Server deutlich und lässt mehr Raum für den Client. Gerade was mobile Endgeräte angeht, sollte man hier mehr machen, als point-und-klick anzubieten.

Interessanterweise hat Rails schon früh - vielleicht nicht begriffen aber doch geahnt - das ein API parallel zur App entscheidend ist und es besonders einfach gemacht, APIs zu bauen, die nacktes JSON liefern. Django war (den ist-Stand kenne ich nicht mehr wirklich) zumindest früher stark in der klassischen CMS-Denke, wo das CMS eben Webseiten erzeugt.

Point-und-Klick. Eine Idee aus Smalltalk, ca. 1975, davor schon von Doug "Mr. Mouse" Engelbart und Ivan "Sketchpad" Sutherland (da war's noch ein Lichtgriffel AFAIK). Seit Ende der 80ern geistert die Idee der "direkt manipulation" aka Drag-und-Drop durch die GUIs, doch bis auf ein paar Dateien im Filebrowser zu verschieben, hat sich das nicht wirklich durchgesetzt. Schade eigentlich. Gerade ein Touch-Interface, das man mit Fingern bedient, ist dafür ideal geeignet.

Hinzu kommen Gesten wie "pinch", "pan" und "swipe" (also zoomen, scrollen und wischen, die bei Android aus Patent-Gründen wohl leicht anderes heißen) und Sensoren (Lage, Licht, später vielleicht auch mal Temperatur, Geo-Position, usw.), deren Status man ebenfalls als Eingabe werten kann.

Ach ja, und es gibt nicht nur einen Finger, sondern mehrere. Wieso kann ich bei meinem Patience-Spiel auf dem iPad nicht zwei Karten mit zwei Fingern auf einmal verschieben? Ich möchte es z.B. auch gemeinsam spielen. Die entsprechenden Events unter iOS bieten diese Information standardmäßig an, aber der Programmierer war zu faul oder unwissend, das zu nutzen, vielleicht hat er auch, was ich glaube, eine Abstraktion über iOS benutzt, die mir dieses Features genommen hat. Für kostenlos kann ich da ja wohl mehr erwarten, oder? ;)

Was ich sagen will: Je weiter weg man vom OS ist - nicht nur technisch sondern auch gedanklich wie bzw. der Idee, mobile Apps mit HTML zu bauen, weil man einen anderen Ansatz portiert hat (Großrechner Terminals mit Masken zum Ausfüllen die man dann "submittet") - desto schlechter kann das Ergebnis sein. Manchmal ist das egal, denn alles was man will, ist eine Liste von SuperdealsDeals sortiert nach Entfernung zum aktuellen Standort anzeigen. Das braucht keine Interaktion.

Manchmal aber nicht. Wer kennt Gapminder, ein Tool, das erlaubt, Statistiken interaktiv zu erforschen (und dann wie ein Sportreporter darüber zu berichten, wenn man Hans Rosling heißt). Das wäre ideal für eine pinch-panch-Touch-Oberfläche geeignet. Wahrscheinlich ließe sich das ganze im Browser realisieren. iPad hat hardware-beschleunigtes SVG, bei Android 4 (welches Trauerspiel, kündigte Acer doch gerade erst noch ein 7"-Tablet mit 3.2 an) bin ich mir gerade nicht sicher. Doch man das ganze dann speziell in JavaScript schreiben, wahrscheinlich je eine Version für Desktop und eine für Tablet. Native ginge es natürlich in jedem Fall.

Jetzt bin ich aber vollends vom Thema weg. Für alles, was irgendwie als Webapps bezeichnet werden könnte, geht der Trend weg von HTML hin zu JavaScript - oder einer Sprache, die dann in JavaScript kompiliert. Der Kampf zwischen den JavaScript-Client-Rahmenwerken ist entbrannt und 10+ Contender stehen bereit. Der Server hat verloren bzw. hier ist es einfach. Er stellt Daten zur Verfügung. Natürlich wird es auch Websites wie früher geben und auch nicht weniger als früher, doch relativ gesehen zu allem, was sonst so im "Web" kreucht und fleucht, nimmt die Bedeutung ab.

Das wir die Gerüste für Apps in HTML und mit CSS bauen, ist genau so sehr ein historischer Unfall wie es einfach bequem ist. Ein Label, in dem ein Wort fett geschrieben ist, ist unter iOS eine schwierige Aufgabe, die einen schon eine Stunde beschäftigen kann, in HTML ist es ein no-brainer.

Übrigens, ZURB Foundation ist ein tollen Rahmenwerk, wenn man Websites prototypisieren oder richtig bauen will, die automatisch "responsive" sind, d.h. von Handy über Tablet bis zum Desktop ein- oder mehrspaltig umbrechen und vernünftige Defaults haben. Twitters Bootstrap kann das in Version 2 auch, scheint mir aber schon deutlich größer geworden zu sein, vielleicht zu groß für den "kleiner ist feiner"-Contest.
</rant>

Stefan
burli
User
Beiträge: 1156
Registriert: Dienstag 9. März 2004, 18:22

Öhm, ja, langer Text :)

Mir geht es nicht darum, dass eine App Nativ auf irgend einem OS aussieht. Ich möchte eine Webseite programmieren, die einmal einen "normalen" Frontend für den Desktop hat und ein Interface für Touch Devices. Eventuell sogar unterschiedliche für Smartphones und Tablets, da ein Smartphone mit 4" Display nochmal anderen Anforderungen hat als ein Tablet mit 10".

Mit Ajax werde ich wohl so oder so arbeiten, aber nicht unbedingt so extrem wie es JQM auslebt. Ich denke, ich werde statt JQM eben eine entsprechende Oberfläche mit HTML und CSS Mitteln bauen, für jedes Endgerät eben eine eigene. JQM ergibt eigentlich nur auf Smartphones wirklich Sinn.
Das schwierigste beim Programmieren ist, sinnvolle Variablen- und Funktionsnamen zu finden :lol:
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

burli hat geschrieben:Ich denke, ich werde statt JQM eben eine entsprechende Oberfläche mit HTML und CSS Mitteln bauen, für jedes Endgerät eben eine eigene. JQM ergibt eigentlich nur auf Smartphones wirklich Sinn.
Schau dir Zurb Foundation oder Twitter Bootstrap an. Das sollte für deinen Zweck besser sein als JQM.

Stefan
burli
User
Beiträge: 1156
Registriert: Dienstag 9. März 2004, 18:22

sma hat geschrieben: Schau dir Zurb Foundation oder Twitter Bootstrap an. Das sollte für deinen Zweck besser sein als JQM.
So auf den ersten Blick erinnert das an YAML
Das schwierigste beim Programmieren ist, sinnvolle Variablen- und Funktionsnamen zu finden :lol:
Antworten