Admin Interface für SQLAlchemy mit ExtJS

[lunar]

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.

Ok, wenn du Javascript mit PHP vergleichst, hast du entweder wenig Ahnung von PHP oder wenig Ahnung von Javascript. Und die Ausführung auf dem Client ist doch gerade das Nette an Javascript, es ist rational betrachtet nämlich einfach nur dämlich, bei minimalen Änderungen an der GUI diese komplett neu zu verschicken.

[veers]

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

Hi Dauerbaustelle,

Hast du dich einmal wirklich mit Javascript befasst und damit eine grössere Anwendung geschrieben? Wenn ja, wo traten praktische Probleme die an Javascript als Sprache lagen auf?

Mit der Aussage das Javascript saulahm ist wäre ich vorsichtig. Zuerst einmal ist Javascript eine Sprache, Sprachen sind nicht lahm oder schnell.
Zum anderen sind derzeit einige sehr schnelle Javascript Implementierungen in Entwicklung. Googles V8 ist vermutlich jetzt schon schneller als Python.

Das Hauptproblem mit Ext, was du vielleicht als "saulahm" bezeichnest ist die Grösse. So kann ich volles ext-build schon 500kb erreichen. Das ist für ein Admin Interface jedoch nicht wirklich ein Problem, zumal ja gecacht wird. Wenn Ext mal geladen ist lässt sich die Anwendung jedoch im ein vielfaches schneller bedienen als eine herkömmliche Webanwendung. Für ein Admin Interface finde ich es auch durchaus ok einen Browser welcher Javascript unterstützt vorauszusetzen.

Jonas

[Dauerbaustelle]

@veers, lunar: Ich habe mich durchaus schon ausführlich mit PHP und Javascript befasst und vergleiche die beiden in ihrer Grottigkeit. Wobei Javascript einen Ticken besser ist als PHP. Natürlich ist Javascript oftmals gut, wenn man es sparsam einsetzt, zum Beispiel an Stellen, wo eine Sortierung einer Tabelle stattfindet, oder das Abschicken eines kleinen Formulares, um zum Beispiel einen Eintrag hinzuzufügen usw. Aber das komplette UI mit JS zu erstellen, finde ich aus Barrierefreiheits-Gründen eine schlechte Idee.
Natürlich hat eine Sprache keine Geschwindigkeit. Allerdings dauert zum Beispiel der Aufbau eines Javascript-GUI sehr viel länger, als wenn das Ganze als HTML kommt. Ich meine damit nicht die *Versendezeit*, sondern die *Renderingzeit*.

[veers]

Was ist den an Javascript so grottig?

Aber das komplette UI mit JS zu erstellen, finde ich aus Barrierefreiheits-Gründen eine schlechte Idee.

Kannst du mir erklären warum Javascript nicht Barrierefrei sein soll und wie viele Administratoren mit einer Behinderung als Admin mit deinen Webanwendungen arbeiten?

[derdon]

@Dauerbaustelle: Du vergleichst nicht nur JavaScript mit PHP, sondern auch JavaScript mit HTML?

[lunar]

@veers, lunar: Ich habe mich durchaus schon ausführlich mit PHP und Javascript befasst und vergleiche die beiden in ihrer Grottigkeit.

Glücklicherweise muss ich nicht einer Meinung mit dir sein ...

[Dauerbaustelle]

Was ist den an Javascript so grottig?

Die Semikola, die geschweiften Klammern, die schlechte OO,...

Kannst du mir erklären warum Javascript nicht Barrierefrei sein soll und wie viele Administratoren mit einer Behinderung als Admin mit deinen Webanwendungen arbeiten?

Schonmal was von MIDs gehört? Von Menschen, die aus Sicherheits bzw. Leistungsgründen JS deaktiviert haben?

Don't hurt the web :'(

[Leonidas]

Was ist den an Javascript so grottig?

Die Semikola, die geschweiften Klammern, die schlechte OO,...

Die Syntax kann man vielen anderen Sprachen auch vorwerfen, jedoch ist JavaScript im zusammenspiel mit HTML sehr praktisch, weil HTML die Whitespaces nicht beachtet. Wenn JavaScript das täte, wäre Entwicklung damit 300% schlimmer. Und die OO ist schlecht weil sie Prototypbasiert ist? Also ist das OO in Io und Self automatisch auch schlecht, obwohl sie OO weiter treiben als Python es tut? Der Argumentation kann ich nicht folgen.

Schonmal was von MIDs gehört? Von Menschen, die aus Sicherheits bzw. Leistungsgründen JS deaktiviert haben?

Es geht um ein Admin-Interface da ist es IMHO egal. Wenn deine Seite gefähliches JS einsetzt, dann hast du was falsch gemacht. NoScript hat übrigens auch Whitelists. Und ehrlich, der Leistungsunterschied ohne JS gegenüber dem mit JS ist eher minimal, verglichen mit der Renderzeit der DOM-Elemente.

Ich habe zwar auch Einwände gegenüber ExtJS, aber diese sind nicht ideologisch sondern betreffen eher die Erweiterbarkeit. Aber das habe ich mit veers schon off-site diskutiert und wenn sich herausstellt, dass es da akzeptable Lösungen gibt dann bin ich daran schon allein deswegen interessiert weil es ein neuer Ansatz ist, den ich noch nicht gegangen bin.

[BlackVivi]

Der JavaScript-Hass kommt aus den alten guten Tagen, als die Menschen JS nur eingesetzt haben, um nervige Meldungen und blinkenden Text zu erzeugen... Als der Einsatzzweck von Javascript noch relativ... nervig war, sagen wir's mal so. Die Sprache selbst ist total toll oO Find ich... und hat sogar was von Python. Früher hab ich's gehasst, weil JS nur für Mist eingesetzt wurde... jetzt sehe ich Netvibes, die Sachen auf extJS und denke nur noch "Wow". Natürlich hat JavaScript immernoch Einsatzzwecke wo's toll ist... und manche wo's doof ist.

Ich würde jetzt einen Blog nicht voll damit machen... höchstens bei Sachen (wie aufklappbare Listen aus Kategorien oder sowas...) wo man drauf verzichten kann... So das die Seite auch ohne JavaScript benutzbar bleibt.

Aber es gibt eben auch richtige JS-Applikationen. Für die kann man dann Js anschalten oder man benutzt sie nicht. ... der Sprache selbst ist aber imho fast nix vorzuwerfen. Höchstens... sie ist manchmal ein bissel schwer zu lesen, wenn'n Idiot sie schreibt. Aber bei welcher Sprache is's nich so ?

[str1442]

Der JavaScript-Hass kommt aus den alten guten Tagen, als die Menschen JS nur eingesetzt haben, um nervige Meldungen und blinkenden Text zu erzeugen... Als der Einsatzzweck von Javascript noch relativ... nervig war, sagen wir's mal so.

+ Neben genau solchen Einsatzzwecken sieht man auch oft sehr grauenhaften Javascript Code. Ich habe zum Beispiel erst vor kurzem ein einzeiliges und *extrem* langes eval() Monster Monster gesehen. Das macht dann natürlich unheimlich Spaß.

Ansonsten wird es auch oft dann eingesetzt, wenn es gar nicht nötig wäre. Bei einem Blog zb will ich kein Javascript sehen. Da will ich bloß eine gute Übersicht haben. Genauso wie ich kein riesengroßes Flash Fenster vor der Nase haben will, wenn ich eine Website öffne. Vielleicht bin ich einfach zu minimalistisch / puristisch für "Web 2.0, die Demokratisierung des Netzes" .

Außerdem ist in dem Sprachennamen "Java" drinne, was einen intuitiv natürlich an eine gewisse Sprache denken lässt, die sicher nicht jedem gefällt

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

Und den Prototypenbasierten OOP Ansatz finde ich toll

[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