Admin Interface für SQLAlchemy mit ExtJS

Du hast eine Idee für ein Projekt?
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

Nach einigem experimentieren mit Werkzeug und SQLAlchemy muss ich sagen das mir diese Kombination sehr gut gefällt. Jedoch vermisse ich das Admin Interface von Django. Da ich diese Woche auch noch einige Erfahrungen mit ExtJS sammeln konnte habe ich mir überlegt ob es nicht Toll wäre ein Admin Interface für SQLAlchemy mit ExtJS zu entwickeln.

Nun meine Fragen dazu:
- Gibt es da schon etwas?
- Würdet ihr so etwas verwenden?
- Welche Features wären wichtig für euch?

Cheers,
Jonas
[url=http://29a.ch/]My Website - 29a.ch[/url]
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Oh, apollo13 und ich haben schon sowas diskutiert. Ich denke der Admin ist momentan der Hauptgrund warum ich noch Django nutze - weniger weil ich selbst es brauche, sondern die Leute für die ich das entwickle.

Ich denke schon, dass wenn es etwas Feature-ähnliches zum Django-Admin geben würde, dass ich es nutzen würde. Allerdings gibt es auf der TurboGears-Seite schon zwei Admins die nichts geworden sind, daher bin ich ein wenig skeptisch. Noch dazu dass es bisher keine definitive Form-Library außerhalb von Django gibt, so wie es SQLAlchemy für ORMs gibt.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

Leonidas hat geschrieben:Oh, apollo13 und ich haben schon sowas diskutiert. Ich denke der Admin ist momentan der Hauptgrund warum ich noch Django nutze - weniger weil ich selbst es brauche, sondern die Leute für die ich das entwickle.
Geht mir ähnlich.
Leonidas hat geschrieben:Ich denke schon, dass wenn es etwas Feature-ähnliches zum Django-Admin geben würde, dass ich es nutzen würde. Allerdings gibt es auf der TurboGears-Seite schon zwei Admins die nichts geworden sind, daher bin ich ein wenig skeptisch.
Catwalk? Das baute doch auf SQLObject auf... Oder gibt es da noch mehr? Hast du eine Idee warum nichts aus diesen Wurde?
Leonidas hat geschrieben:Noch dazu dass es bisher keine definitive Form-Library außerhalb von Django gibt, so wie es SQLAlchemy für ORMs gibt.
Das ist so. Liegt aber vermutlich auch daran das man sich relativ einfach ein paar Form-Helper selber hacken kann. Für Client-Side Formulare und Verifikation finde ich ExtJS auf jeden Fall toll.

- Jonas
[url=http://29a.ch/]My Website - 29a.ch[/url]
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

ExtJS ist ein hervorragende Lösung, wenn man eine Webanwendung im Stil von Microsoft Office bauen möchte. Gerade die kommende Version 3.0 wird dort noch einen "draufsetzen", da sie einen VisualStudio-artigen GUI-Designer enthalten soll. Ob der im jetzigen Preis enthalten sein wird oder ein Extraprodukt sein wird, weiß ich allerdings nicht.

Ich kann mir vorstellen, dass ExtJS daher für ein UI zur Stammdatenverwaltung sehr gut geeignet ist. Ich würde erwarten, dass Daten tabellarisch per Grid angezeigt werden können, dort sortiert und gefiltert werden und per Ajax nachgeladen werden, sodass man niemals "pagen" muss. Gerade das "grouping"-Feature fände ich sehr interessant, um Daten besser zu präsentieren.

Will man nicht nur direkt die Zellen bearbeiten, kann mit dem Forms-Rahmenwerk schicke Dialoge inklusive Tabs und eines Date-Pickers und einfache WYSIWYG-Editors haben, die Valdierung der Daten unterstützen.

Zusammen kann man auch Master-Detail-Darstellungen machen, die neben oder unter einer tabellarischen Darstellung ein Formular anzeigen.

Mit Hilfe der Panels kann man doch außerdem so einen Windows-artigen Desktop mit einer Taskbar bauen, wo man zwischen verschiedenen Fenstern hin und her schalten kann. In jedem Fall könnte man schließbare Tabs wie in einem Browser haben.

Möglichkeiten gibt es also viele.

Ob ich's verwenden würde hängt ein bisschen davon ab, ob ich bereit wäre, die $300 für ExtJS in den jeweiligen Projekt zu zahlen. Das ist zwar jetzt nicht so viel (und ExtJS ist warhscheinlich das beste, was man bekommen kann), aber dennoch ein möglicher Hinderungsgrund. Die GPL-Version zu benutzen wäre u.U. eine Alternative für Hobby-Projekte.

Technisch würde ich mir einen ähnlichen Ansatz wie bei Django vorstellen: Ich beschreibe mit Python-Klassen, wie ich die Objekte einer Tabelle darstellen möchte. Es muss sinnvolle Vorgaben geben, die ich dann anpassen kann. Ich würde mir wünschen, dass wenn man schon ExtJS benutzt, es auch bis zum Anschlag ausreizt und nicht versucht, von dem JavaScript-Rahmenwerk zu abstrahieren. Große Dosen Ajax wäre IMHO Pflicht.

Ich würde mir wünschen, dass ich die Einstiegsseite mit einer gruppierten Liste von Tabellen einfacher als bei Django strukturieren kann, vielleicht so:

Code: Alles auswählen

Site(title="ACME Inc",
    Tab(title="Stammdaten",
        Group(title="Anwender", collapsed=True,
            Table(User, name="Mitarbeiter|Mitarbeiter", meta=(display_count, display_latest)),
            ...
womit ich definiere, dass mein Admin UI "ACME Inc" heißen soll, mindestens einen Tab namens "Stammdaten" hat auf dessen Seite mindestens eine Gruppe namens "Anwender" angezeigt wird (die standardmäßig zusammengeklappt sein könnte) und wo (ein Link für) die Tabelle für "User" dargestellt wird, die Mitarbeiter heißen soll und wo in einer zweiten Zeile (in kleiner Schrift) noch Informationen über die Tabelle angezeigt werden, indem die beiden angeführten Funktionen aufgerufen werden.

Einzelne Tabellen werden als Grid - optional bearbeitbar - dargestellt, wobei man angeben kann, was wie validiert werden soll. Gleichzeitig kann man immer Suchen und Filtern.

Ein Datensatz wird als Formular angezeigt, bei dem ich wählen kann, welche Felder wie gruppiert (auch nebeneinander) in welcher Reihenfolge angezeigt werden. Pro Feld gibt es ein zugeordnetes Widget, was ich bei Bedarf überschreiben kann.

Das ganze muss so erweiterbar sein, dass ich irgendwo noch Knöpfe oder Links für weitere Funktionen einblenden kann.

Idealerweise fragt das Rahmenwerk auch zusammen mit den aktuell angemeldenten User vor dem Anzeigen noch mal nach, ob ich die Menge der Felder vielleicht filtern möchte, um bestimmten Anwendern nur bestimmte Teilmengen der Felder anzuzeigen.

Stefan
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

Vielen Dank für deinen ausführlichen Post, da sind einige gute Ideen dabei!

Zur Lizenz von ExtJS, so wie ich das verstanden habe sind das einmalig 300$ pro Entwickler, oder GPL3 + OpenSource Exceptions.

- Jonas
[url=http://29a.ch/]My Website - 29a.ch[/url]
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

veers hat geschrieben:Vielen Dank für deinen ausführlichen Post, da sind einige gute Ideen dabei!
Gerne doch. Mir fällt auf, dass ich nicht explizit gesagt habe, dass ich die Idee sehr interessant finde. Das sei hiermit nachgeholt.
veers hat geschrieben:Zur Lizenz von ExtJS, so wie ich das verstanden habe sind das einmalig 300$ pro Entwickler, oder GPL3 + OpenSource Exceptions.
Was meinst du mit OS-Exceptions? Ich lese da GPL3 und nur GPL3. Dazu sei einzig die ApachePL2 kompatibel, doch Code unter dieser Lizenz wird dann auch GPLed.

Ansonsten: Da ExtJS IMHO sehr komplex ist, wäre es natürlich toll, ein in Python für Python geschriebenes Admin UI micht mit dem JavaScript von ExtJS nicht belästigen würde und die gesamte Konfiguration für mich übernähme.

Eine andere Idee, die ich schon mal hatte aber noch nicht wirklich durchdacht hatte war, ob man nicht vielleicht Flex als Frontend einsetzen könnte. Das ist alles Open Source und mindestens genauso mächtig, was den Funktionsumfang angeht. Flash ist eh überall vorhanden. Nachteil ist, dass es erst mit einer kommerziellen IDE so richtig Spaß macht, das zu benutuzen. Nun dachte ich, man könnte vielleicht eine Art generischen UI-Interpreter bauen, der über eine vom Server geladene Datei konfiguriert wird, um das selbe unmittelbare "Entwicklungsgefühl" wie bei HTML und JavaScript zu bekommen. Vielleicht will ich mir aber auch einfach nicht eingestehen, dass Silverlight hier einen Vorteil hat ;)

Stefan
derdon
User
Beiträge: 1316
Registriert: Freitag 24. Oktober 2008, 14:32

sma hat geschrieben:Flash ist eh überall vorhanden.
Nope, bei mir nicht. Und Gnash ist auch noch in der Entwicklungsphase, das merkt man auch.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

derdon hat geschrieben:
sma hat geschrieben:Flash ist eh überall vorhanden.
Nope, bei mir nicht.
Bei mir auch nicht. Ich empfinde generell Flash als Katastrophe, das Adobe den Linux-Leuten den Finger zeigt setzt da nur noch einen drauf. Jetzt sind die Spezifikationen zwar in irgendwieweit freigelegt, aber ich finde <video> sowieso besser als diese ganzen unsäglichen Flash-Player. Da fand ich ja schon den WMP in Webseiten eingebettet besser.

Und ja, bei ExtJS habe ich auch so generell meine Bedenken. Klar, es bietet großartige Widgets die man so bisher in keinem anderen Toolkit findet, aber ich bin mir nicht sicher ob ich nun die GPL als Lizenz für eine Library gut finden soll oder nicht.

Und zu den TG-Admin Interfaces: ja, ich meinte CatWalk. Aber das konnte eigentlich dem Django-Admin nie das Wasser reichen und nun wo der Admin auf neforms aufbaut ist er doch ein wenig flexibler geworden. Für SQLAlchemy scheint es DBSprockets und insbesondere dort den DBMechanic zu geben, aber auf den Screenshots sieht der jetzt auch eher wenig beeindruckend aus.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
lunar

Leonidas hat geschrieben:Noch dazu dass es bisher keine definitive Form-Library außerhalb von Django gibt, so wie es SQLAlchemy für ORMs gibt.
Es gibt formencode/formbuild und wtforms. Ersteres ist nicht so meins, aber letzteres ist imho sogar angenehmer als die Django-Form-Bibliotheken.
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

sma hat geschrieben:
veers hat geschrieben:Zur Lizenz von ExtJS, so wie ich das verstanden habe sind das einmalig 300$ pro Entwickler, oder GPL3 + OpenSource Exceptions.
Was meinst du mit OS-Exceptions? Ich lese da GPL3 und nur GPL3. Dazu sei einzig die ApachePL2 kompatibel, doch Code unter dieser Lizenz wird dann auch GPLed.
Siehe http://extjs.com/products/license.php, ganz unten.
[url=http://29a.ch/]My Website - 29a.ch[/url]
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

veers hat geschrieben:Siehe http://extjs.com/products/license.php, ganz unten.
Ah, gut zu wissen. Hatte ich übersehen. Das entschärft das Problem etwas.

Ansonsten wäre die nächstbeste Alternative vielleicht YUI, doch das wirkt auf mich nicht so rund und auf den Anwendungsfall der Datenbank-Anwendung zugeschnitten. Die Grundbausteine müssten aber eigentlich reichen. JQuery, Mootools oder Prototype sind da jedenfalls lange noch nicht angekommen (wollen da vielleicht auch nie hin).

Vom Namen her kenne ich noch Qooxdoo, das wohl im Eclipse-Umfeld (Demo ist quälend langsam, sieht aber etwas frischer aus) genutzt wird, aber irgendwie nicht so richtig schick wirkt.

Zu Flash: Mit der Aussage wollte ich natürlich provozieren, war aber eher unnötig und die richtige Formulierung wäre: Bei der Zielgruppe, an die ich denke, wäre Flash kein Problem. Die Konkurenz für ExtJS und Co sind ja mit VisualBasic oder Access erstellte Datenbank-zentrische Anwendungen, die durch eine Webanwendung ersetzt werden sollen.

Stefan
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

sma hat geschrieben:Zu Flash: Mit der Aussage wollte ich natürlich provozieren, war aber eher unnötig und die richtige Formulierung wäre: Bei der Zielgruppe, an die ich denke, wäre Flash kein Problem. Die Konkurenz für ExtJS und Co sind ja mit VisualBasic oder Access erstellte Datenbank-zentrische Anwendungen, die durch eine Webanwendung ersetzt werden sollen.
Ich denke die Zielgruppe von veers sind eher Django-Leute, die das ORM loswerden aber den Admin behalten wollen bzw. sogar einen besseren möchten. Denen dann Flash zu servieren, halte ich, naja, für ziemlich ungeschickt.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Leonidas hat geschrieben:Ich denke die Zielgruppe von veers sind eher Django-Leute, die das ORM loswerden aber den Admin behalten wollen bzw. sogar einen besseren möchten.
Mag sein. Dann sollte man aber zusehen, dass das möglichst kompatibel wird (ähnlich wie Jinja kompatibel zu Djangos Template-Sprache ist) wenn man Umsteiger überzeugen will.
Leonidas hat geschrieben:Denen dann Flash zu servieren, halte ich, naja, für ziemlich ungeschickt.
Wäre dann aber prinzipiell nicht auch ExtJS ein Problem?

Ich habe da einen Anwendungsfall im Auge wo ich weiß, dass Djangos ORM ungenügend ist, wo ich aber mit einer automagischen Stammdatenverwaltung (aka Admin UI) viel Zeit sparen könnte. Weder Flash noch ExtJS wären da ein Problem. Wichtig wäre, dass das ähnlich genug zu einer existierenden Windows-Anwendung ist, da das (nicht unberechtigte) Vorurteil herrscht, dass eine Webanwendung zu primitiv im Bedienkomfort ist.

Welche Alternativen (Silverlight? JavaFX?) hätte man sonst für ein modernes UI für Tabellen (ohne Paging) und Formulare (mit Validierung)?

Stefan
lunar

sma hat geschrieben:
Leonidas hat geschrieben:Ich denke die Zielgruppe von veers sind eher Django-Leute, die das ORM loswerden aber den Admin behalten wollen bzw. sogar einen besseren möchten.
Mag sein. Dann sollte man aber zusehen, dass das möglichst kompatibel wird (ähnlich wie Jinja kompatibel zu Djangos Template-Sprache ist) wenn man Umsteiger überzeugen will.
Die Frage ist, ob man Umsteiger tatsächlich überzeugen will, oder man einfach nur ein SQLAlchemy-Admin-Interface bauen will. In letzterem Fall kann einem Kompatibilität zu Django ja reichlich egal sein, und so wie ich veers Posting interpretiere, ist Kompatibilität nicht wirklich nötig.
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Was könnte denn ein SQLalchemy-Admin-Interface mehr oder weniger als z.B. phpmyadmin? Will man nicht eher ein Admin-UI für seine Anwendung und sein Datenmodell haben? Oder meintest du das? Man will doch von der Datenbank und seinen Tabellen abstrahieren, oder?

Ich hatte mir übrigens eben mal ein bisschen ExtJS angeschaut. Der HTML-Anteil (und damit, was ein template leisten müsste) ist ja eher minimal, wenn man sich mal ein Form anschaut:

Code: Alles auswählen

<div id="hier-mein-form"></div>
Der Rest ist JavaScript oder könnt JSON sein. Ich würde jetzt tippen, dass man einmal in JavaScript quasi einen Interpreter für eine Form-DSL schreibt und dieser erzeugt dann zur Laufzeit die Forumuare aus der vom Server erstellten Beschreibung. Theoretisch könnte man auch gleich eine Modellbeschreibung schicken und der Client erzeugt dann auch noch daraus selbst die Abbildung auf die Form-Widgets, ist aber wohl nicht praktikabel.

Sowas müsste dann erzeugt werden:

Code: Alles auswählen

new Ext.form.FormPanel({
  renderTo:"hier-mein-form",
  frame:true,
  title:"Anmeldung",
  width:425,
  labelAlign:"top", // Labels über den Fields, sieht netter aus
  items: [
    new Ext.form.TextField({
      id:"username",
      fieldLabel:"Benutzername",
      width:275,
      allowBlank:false,
      blankText:"Hier bitte Name eingeben",
      regex:/\w+/,
      regexText:"Nur Zeichen und Zahlen sind erlaubt",
      selectOnFocus:True
    }),
    new Ext.form.TextField({
      id:"password",
      fieldLabel:"Kennwort",
      width:275,
      allowBlank:false,
      blankText:"Kennwort nicht vergessen!",
      inputType:"password"
    })
  ],
  buttons: [
    {text:'Anmelden'},
    {text:'Abbrechen'}
  ]
});
Da lassen sich noch viel mehr Attribute setzen und die Buttons müssten auch noch mit Funktionen versehen werden, aber es gibt einen Eindruck von dem, was erzeugt werden muss. Ich würde außerdem erwarten (einfach weil es möglich ist), dass auf dem Mac bitte Anmelden und Abbrechen vertauscht werden, da hier die Reihenfolge eine andere als unter Windows ist).

Mehrspaltige oder mehrseitige Formulare gehen natürlich auch, allerdings weiß ich nicht, ob der Layouter es beherrscht, Labels vor einem Eingabfeld dann immer gleich breit zu machen - das waren so Dinge, mit denen ich mich vor Jahren mit Java und dafür speziell geschriebenen LayoutManagern herumgeschlagen hatte. Das JGoodies-FormLayout war da ungeschlagen.

Stefan
lunar

sma hat geschrieben:Was könnte denn ein SQLalchemy-Admin-Interface mehr oder weniger als z.B. phpmyadmin? Will man nicht eher ein Admin-UI für seine Anwendung und sein Datenmodell haben? Oder meintest du das?
Ja. SQLAlchemy verwaltet ja auch nicht so sehr die "Datenbank" (zumindest wenn man die ORM-Schicht nutzt), sondern persistente Objekte. Ich meinte halt das Admin-Interface von Django, aber eben mit SQLAlchemy als ORM-Backend. Nur muss man halt nicht unbedingt API-Kompatibilität zu Django herstellen, um möglichst viele Django-Nutzer zu bekehren.
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

Leonidas hat geschrieben:Und ja, bei ExtJS habe ich auch so generell meine Bedenken. Klar, es bietet großartige Widgets die man so bisher in keinem anderen Toolkit findet,
Die Widgets sind das eine. Was ich noch wichtiger finde ist das Ext eine gute, MVC artige Architektur hat.
Leonidas hat geschrieben:aber ich bin mir nicht sicher ob ich nun die GPL als Lizenz für eine Library gut finden soll oder nicht.
Reine GPL fände ich ziemlich Problematisch. Mit den Exceptions, und den Preisen für Kommerzielle Benutzung finde ich es ok. Was mich an Ext mehr stört ist das die Repositories nur für bezahlte Kunden offen sind (wtf?) und das sie relativ Plötzlich von LGPL auf GPL gewechselt haben.
lunar hat geschrieben:
sma hat geschrieben:
Leonidas hat geschrieben:Ich denke die Zielgruppe von veers sind eher Django-Leute, die das ORM loswerden aber den Admin behalten wollen bzw. sogar einen besseren möchten.
Mag sein. Dann sollte man aber zusehen, dass das möglichst kompatibel wird (ähnlich wie Jinja kompatibel zu Djangos Template-Sprache ist) wenn man Umsteiger überzeugen will.
Die Frage ist, ob man Umsteiger tatsächlich überzeugen will, oder man einfach nur ein SQLAlchemy-Admin-Interface bauen will. In letzterem Fall kann einem Kompatibilität zu Django ja reichlich egal sein, und so wie ich veers Posting interpretiere, ist Kompatibilität nicht wirklich nötig.
Ich tendiere eher zu letzterem.

Wer mit Django glücklich ist - toll. Mir gefällt an Django jedoch so einiges nicht (soll nicht heissen das ich Django nicht mag, aber es ist eine Ansammlung suboptimaler Komponenten).

sma,
labelWidth solltest du auch pro Feld, ganz bestimmt pro Textfeld setzen können.

lunar,
So sehe ich das auch.

Gruss,
Jonas
[url=http://29a.ch/]My Website - 29a.ch[/url]
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
Dauerbaustelle
User
Beiträge: 996
Registriert: Mittwoch 9. Januar 2008, 13:48

Admininterface für sqlalchemy hört sich gut an. Aber warum Javascript? Das ist doch fast so grottig wie PHP -.-
lunar

Dauerbaustelle hat geschrieben:Admininterface für sqlalchemy hört sich gut an. Aber warum Javascript? Das ist doch fast so grottig wie PHP -.-
Meinst du als Sprache oder stört dich einfach nur die Tatsache, dass es auf dem Client ausgeführt wird?
Dauerbaustelle
User
Beiträge: 996
Registriert: Mittwoch 9. Januar 2008, 13:48

lunar hat geschrieben: Meinst du als Sprache oder stört dich einfach nur die Tatsache, dass es auf dem Client ausgeführt wird?
Beides; wobei zweiteres gewichtiger ist. Javascript (ExtJS) ist saulahm. Und ohne JS gings dann janich.
Antworten