Admin Interface für SQLAlchemy mit ExtJS

[DasIch]

Ich würde jetzt einen Blog nicht voll damit machen...

Wieso den nicht? Also ich finds genial

[Leonidas]

Von Javascript selbst habe ich allerdings keine Ahnung, aber mit Java scheint sie nicht viel gemein zu haben, wenn ich das hier so lese.

Hat es auch nicht. Wurde eigentlich eher als Scheme für den Browser von Brendan Eich entwickelt aber vor dem Release wurde die Syntax verändert. Und aus Mocha wurde erst LiveScript und dann JavaScript um auf den Java-Hype damals aufzuspringen.

[sma]

Statt unsäglicher und unnötiger Diskussion über JavaScript würde ich lieber wissen, ob etwas Neues zu diesem Thema gibt. Ich finde die Idee nach wie vor spannend und lieber über mögliche Umsetzungsstrategien reden.

Stefan

[veers]

Statt unsäglicher und unnötiger Diskussion über JavaScript würde ich lieber wissen, ob etwas Neues zu diesem Thema gibt. Ich finde die Idee nach wie vor spannend und lieber über mögliche Umsetzungsstrategien reden.

Stefan

Ok, Status:

Ich hab einen Namen: adminalchemy, oder wie Leonidas vorgeschlagen hat admiralchemy Ich denke der ist passend, es ist sofort klar worum es geht, ohne das es zu offiziell tönt.

Ich hab eine Vorstellung vom UI:
- Header oben, da kann man dann einen Titel oder ein Logo rein packen.
- Links ein Baum, in dem die einzelnen Module (User Management), und Models (User) auswählen kann.
- Rechts ist Platz für ein Grid, mit Toolbar für Aktionen wie Add, Remove, Edit möglicherweise noch weitere. Später könnten hier noch weitere Views wie Trees folgen.

Ich habe eine Vorstellung vom Interface:
- AdminInterface
- Application (Serviert ein AdminInterface via WSGI)
- Model (Abstraktion von SQLAlchemy Mapper)
- Grid (Eine View welche Rechts angezeigt wird)
- Form
- FieldSet
- Field
- NavigationNode

Ich habe ein Modul um aus Python Javascript Objektstrukturen zu erstellen, wovon ich gerade gemerkt habe das ich dieses nicht mehr finden kann.

Und ich habe eine Vorstellung wie sich das Ganze Implementieren lässt. Jedoch bin ich mir nicht so sicher wie gut das ganze dann so funktioniert. Aber das wird sich dann ja zeigen.

Wo ich mir nicht so ganz sicher bin ist ob ich die Logik zum generieren des ExtJS Code in die Daten Objekte packen will, oder in einen separaten Renderer.

Soweit so gut, der nächste Schritt wäre nun mal das Zusammenhacken eines Prototyps, und eines Beispiels. Damit werde ich dann Anfangen sobald ich wieder einigermassen fit bin

- Jonas

[brickenstein]

Hi!
Schaut Euch mal RUM an.

http://rumdemo.toscawidgets.org/
http://toscawidgets.org/documentation/rum/

Ich bin einer der Mitentwickler.
Ich habe vorher schon in DBMechanik/DBSprockets als Contributor/Coautor Erfahrung gesammelt.

RUMs Hauptautor Alberto Valverde hat ein absolut geniales Design entwickelt,
dass es erlaubt RUM-Applikationen leicht anzupassen.

Als JavaScript Framework setzen wir auf Dojo.

Bevor Ihr was Neues anfangt, würde ich Euch herzlich einladen, an dem Projekt mitzuwirken.
Gruß,
Michael

[sma]

Hm, die Demo-Seite ist gerade unglaublich langsam und wirft bei meinen Versuch, einen Datensatz anzulegen, HTTP 500.

Der Webseite entnehme ich, dass das ganze noch nicht offiziell gelauncht wurde. Mein Tipp wäre, unbedingt eine kurze Feature-Beschreibung und Screenshots und vielleicht ein kleines Tutorial hinzuzufügen. Beantwortet werden sollten die Fragen "Was ist ToscaWidgets" und "Was unterscheidet es von anderen ähnlichen Projekten". Warum ist es besser? Was macht es besonders? Warum sollte ich es einsetzen?

Klicke ich jetzt auf Dcumentation, muss ich mich für eines der gelisteten Projekte entscheiden, ohne eine weitere Entscheidungshilfe geboten zu bekommen. Wähle ich den ersten Link, sehe ich ein Inhaltsverzeichnis, bei dem ich lerne, dass man von "tw.api" importieren soll (nur was?) und das es z.B. unter Core Widgets eine Klasse Widget gibt, doch wozu dient die? Unter Examples sehe ich glue code für verschiendste Rahmenwerke, aber nicht den eigentlichen Beispielcode! Spätestens damit habt ihr mich verloren.

An der Idee mit dem Admin UI für SQLalchemy fand ich übrigens den ExtJS-Aspekt am interessantesten. Somit wäre ToscaWidgets mit Dojo jetzt eher ein Seitenzweig. Gerne würde ich aber hier mehr über das "absolut geniale Design" hören, das da entwickelt wurde.

Stefan

[derdon]

@brickenstein: Guck dir mal ein CSS-Tutorial zum Thema Floats an Auf der Seite http://toscawidgets.org/documentation/rum/ soll "Table of Contents" bestimmt als rechte Spalte um den restlichen Inhalt fließen.

[brickenstein]

Hi!

Da die Demoseite so langsam ist, verweise ich mal auf ein paar schicke Screenshots:

Toscawidgets sind Seitenelemente und kapseln CSS, HTML/Template und Javascript Resourcen. CSS/JS werden automatischen in den Header hinzugefügt.

Verschiedene Einheiten z.B. Darstellung/Editierung von Werten in RUM werden durch Widgets realisiert.
Insbesondere lassen sich so leicht fortgeschrittene Elemente eingliedern.

In diesem Beispiel, wurden für die Tabelleneinträge
"ExpandableSpans" benutzt:
Klappt auf, wenn man drauf klickt (funktioniert bei enstsprechender Konfiguration auch
für formatierte Inhalte).

http://toscawidgets.org/trac/rum/wiki/E ... ?version=3

Ein anderer schöner Screenshot ist dieser hier:

http://toscawidgets.org/trac/rum/attach ... 12/pil.jpg

Ein binäres Feld wurde als Bild konfiguriert:

Code: Alles auswählen

fields.JPEGImage('poster', label=_('Poster in JPEG format'))

Mittels Peak Rules ist der Controller Code erweiter.
Einige dieser Regeln besagen, dass für Binärfelder ein spezieller Controller
eingerichtet wird, der download-Möglichkeiten bietet, bzw. für Bilder sogar
den download einer Preview-Version anbietet (verkleinert mittels PIL).
Dieses System ist komplett durch den Benutzer erweiterbar.


RUM ist in drei Teile geteilt:
Im Herzen:
- RUM, controller, zentrale Architektur, Festlegung des Zusammenspiels
- RUMAlchemy, Implementation eines RUM-Repositories (Datenquelle) mittels SQLAlchemy
- tw.rum, view basierend auf Toscawidgets.

@sma
Wenn Dich der ExtJS am meisten interessiert und Du vielleicht sogar zu Rich Clients neigst, kannst Du auch ohne tw.rum, die serverseitigen Komponenten verwenden, eine Rich Client Anwendung auf RUM aufzubauen. RUM ist darauf designed auch das möglich zu machen:
JSON-Unterstützung ist miteingebaut.



Gruß,
Michael

[veers]

So, es wird einmal wieder Zeit für ein Status Update.

Zuerst zu RUM: Internal Server Error.
Auch von der Instabilität abgesehen gefällt mir der Ansatz aus verschiedenen Gründen weniger. Wäre aber durchaus Interessiert daran wenn es dann mal toll Funktioniert. Danke für den Hinweis auf jeden Fall!

Ansonsten befinde ich mich immer noch in der Experimentier-/Prototypen- Phase. Mal sehen was daraus wird!

- Jonas

[sma]

Ich träume ja inzwischen von einem eher explorativen UI a la Microsoft Quadrant. Das müsste man auch als Webanwendung realisieren können... ist zwar komplexer in der Darstellung, aber richtig cool ;)

Stefan

[Y0Gi]

Zunächst mal habe ich diverse Projekte mittlerweile auf Werkzeug und SQLAlchemy umgestellt und es ist definitiv das Beste, was ich bisher benutzt habe.

Ein Frontend würde mir sehr gefallen. Meine langjährige JavaScript-Abstinenz habe ich durch jQuery wieder aufgegeben. Seit kurzem arbeite ich mit ExtJS und bin davon für entsprechend geeignete Einsatzzwecke recht angetan (auf jeden Fall besser als qooxdoo sowie diverse halbherzige JS-UI-Lösungen). JavaScript ist in abgestecktem Einsatz (z. B. eben nur für Administratoren) durchaus akzeptabel, eine der besten Lösungen für clientseitige Programmierung (zumal browserübergreifend von Haus aus vorhanden und durch jüngste Entwicklungen mit enormem Geschwindigkeitszuwachs) im Web und vereinfacht für mich die Programmierung von Web-Anwendungen dadurch enorm, dass ich viele Requests nur noch mit einem 200 oder 204 anstatt von Redirects oder Template-Platzhalter-Füllungen beantworte und dann per JS das weitere Verhalten festlege.

Mir gefällt also die Kombination dieser drei Komponenten zu einem DB-(Schema-)Frontend sehr gut und ich traue veers das auch zu. Die Lizenz von ExtJS sollte keine unnötigen Einschränkungen mit sich bringen; GPL(3) an sich bietet sich vielleicht sogar an, nur die Einschränkungen gegenüber den Entwicklern durch den ExtJS-Hersteller sind teilweise wirklich unschön.

Wichtig ist mir, dass an dem Gelöt später kein Klimmbimm wie Django oder TurboGears (und das trifft IIRC für ToscaWidgets und damit RUM zu, nehme ich an?) dranhängt, sondern es schlank daher kommt.

Ich selbst habe übrigens irgendwann endlich PHP von meinem Server verbannt - und damit auch phpMyAdmin. Und bald auch MySQL. Daher würde ich eine Lösung sehr freuen, die:
- kein PHP benötigt
- mit MySQL, PostgreSQL und generell recht DBMS-unabhängig funktioniert (was SA ja in recht großem Stil bietet)
- auf dem Server läuft (auch wenn GUI-Client und ssh für mich bisher eine akzeptable Lösung darstellen)
- am Ende keinen doofen Namen ("pythonSqlAdmin") hat

[Leonidas]

Ich selbst habe übrigens irgendwann endlich PHP von meinem Server verbannt - und damit auch phpMyAdmin.

Oh, ich sehe dass ich nicht der einzige bin, der Sicherheit/Administrationsaufwand gegeneinander abgewägt hat und PHP und MySQL den Laufpass gegeben hat.

[Y0Gi]

So sieht's aus. Da ich nicht in der Verlegenheit bin, in PHP geschriebene Anwendungen auf meinem Server laufen zu lassen und mir die zahlreichen PHP-Angriffsversuche in meinen Logs doch etwas zu denken gegeben haben, war für mich der Preis für phpMyAdmin zu hoch. Zwar erfordern Client-GUI-Anwendungen die lokale Installation auf dem System, von dem aus man sie benutzen will. Dafür ist ein SSH-Portforward deutlich sicherer und einfacher, als phpMyAdmin nach Außen abzudichten, wo es doch grundlegend von jedem mit einem Webbrowser zugänglich ist, wenn man in der Konfiguration doch mal irgendwie Mist gebaut hat.

Zu PostgreSQL migriere ich gerade, weil *richtige* FK-Abhängigkeiten, vernünftiger Umgang mit Unicode etc. doch irgendwie wichtig oder zumindest hilfreich sind. Spätestens bei dem Versuch, die abartigen Exports von MySQL in ein zumindest nennenswert standardkonformes RDBMS zu importieren, hat sich mir die Richtigkeit dieser Entscheidung erschlossen.

Um wieder den Bogen zum Thema zu schlagen: Mit dem angedachten Tool sollte es möglich sein, es lokal zu installieren und zu nutzen, um dabei auf eine entfernte Datenbank zuzugreifen, um eine Offenbarung per Webserver mit anschließend erforderlicher Absicherung zu vermeiden. Das sollte sogar phpMyAdmin können.

[brickenstein]

Die Fehler haben mit dem Server zu tun (es ist allerdings geplant toscawidgets.org demnächst auf einen anderen Server zu migrieren).
Wer RUM lokal ausprobieren möchte,
findet hier eine Anleitung:
http://groups.google.com/group/turbogea ... a5f7866963
Gruß,
Michael

[Y0Gi]

Worauf basiert TG bzw. die verwendete Version diesbezüglich eigentlich? Klar, Abhängigkeiten in allen Ehren, aber für so ein Tool möchte ich das ganze Geraffel (insbesondere wenn so halbgares Zeug wie Paste im Hintergrund sitzt) eigentlich ungern installieren. Genau deswegen gefällt mir ja Werkzeug so gut, weil es eine durchdachte Basis darstellt ohne Boilerplate-Code mitzubringen. Weniger ist mehr und so

[brickenstein]

Zuallererst:
RUM ist unabhängig von TG (als WSGI-Applikation).
D.h. RUM ist insbesondere in jede andere
(mittels Deines Lieblings WSGI-Framework geschriebene)
WSGI-Applikation
einbinden
und kann dort über PEAK Rules z.B. die Userauthentifizierungsdaten,
die Deine Anwendung liefert,
berücksichtigen.

Ein paar Komponenten wie WebOb,...
benutzen wir schon direkt in RUM.

Zu TG:
TurboGears 1 baut auf CherryPy, Kid, SQLObject/SQLAlchemy auf
TurboGears 2 wechselt von CherryPy -> Pylons/Paste.

Das Verhältnis von TG zu RUM ist, dass RUM als GSOC-Projekt für TurboGears entstanden ist.
Warum Du allerdings Paste als halbgares Zeug bezeichnest ist mir nicht ganz klar.

Gruß,
Michael

[Y0Gi]

Ich kann dir nicht ganz folgen. Basiert RUM also nicht auf dem TG-Framework, sondern ist eine eigenständige WSGI-Applikation mit WebOb als WSGI-Adapter?

Dass du von der Einbindung von RUM in eine andere Anwendung redest, ist interessant. Bisher hatte ich eine separate Anwendung vor Augen; kann RUM das auch sein? Als generisches Frontend für eine Datenbank, die es mittels der Fähigkeiten von SQLAlchemy reflektiert?

[brickenstein]

Eigentlich hast Du das schon recht gut verstanden:
RUM basiert nicht auf TurboGears, sondern ist eine reine WSGI-Applikation.

RUM kann man auch im stand-alone Modus betreiben, gar kein Problem.
Normalerweise ist das auch das, was wir während der Entwicklung tun.

Zur Reflektion:
Ich habe an Datenbankreflektion im Stil von SQLSoup gearbeitet.
Für Testzwecke (um RUM zu testen) und sehr kleine Projekte kann das interessant sein.
Es gibt ein Skript, das man aufrufen kann:
rumalchemy [options] url
wobei die URL die URL der Datenbank ist.

Für einen ersthaften Einsatz würde ich in jedem Fall empfehlen ein SQLAlchemy-Model zu schreiben, weil man gewisse Dinge doch anpassen kann.
Das SQLAlchemy-Model selbst kann allerdings, wenn Du das (wie ich) bevorzugst, die Tabellen selbst von der Datenbank reflektieren und nur einige wenige Dinge anpassen.

Soweit ich Deinen Einsatszweck verstanden habe, sollte es gut dafür geeignet sein: als generisches Frontend für Datenbanken.
Gruß,
Michael

[Y0Gi]

Ah, das hört sich doch schon besser an.

Eigentlich bevorzuge ich es, das Model in Python zu definieren und daraus dann SQL-CREATE-Statements zu generieren. Ein Frontend möchte ich aber nicht in jede Anwendung integrieren und unabhängiges möchte ich nicht mit dem Model füttern (Import-Abhängigkeiten des Models etc.). Daher würde ich eine zentrale Instanz des Frontends vorziehen, die eben Reflektion nutzt.

[brickenstein]

Also wie gesagt, wir haben eine Reflektionsebene, die nur unter Angabe der URL funktioniert.

Du solltest einfach erst einmal ausprobieren, ob das für Deine Zwecke ausreicht.
RUM ist sehr mächtig, d.h. wir zielen auch darauf, dass man es Endnutzern in die Hand geben kann.
Reflektion funktioniert bis zu einem bestimmten Grad gut:
- Spaltentypen auslesen
- Eigenschaften wie nullable, maximale Lenge von Texteinträgen reflektiere
- einige Relationen erkennen (vor Allem one-to-many)

Problematischer wird es bei Dingen, wie dem Zusammenspiel von Tabellen (Relationen).

Aber probier es erst einmal einfach aus, wie es mit Deinen Daten aussieht.

Unser Code, die Modelle automatisch zu erstellen beruht auf einer verbesserten Version von SQLSoup.

Gruß,
Michael