|
|
|
|
|
|
|
Hallo Leute,
ich habe die Arbeit an meinem JavaScript Toolkit gara soweit beendet, als dass ich eine erste Beta rausbringen konnte. Das Toolkit hält sich dabei an die Syntax von Eclipse SWT/JFace. Es gibt also auf der einen Seite ein Set von Widgets (jsWT) die mit Hilfe der Views (jsFace) leicht als MVC Pattern genutzt werden können.
Schaut euch mal die Demo an, baut vlt. selber ein bisschen. Vlt. kommt ja sogar ein Bugreport rein oder es verliebt sich gar einer in das Toolkit 
Ich freue ich über Feedback!
Homepage: http://gara.creative2.net
- uni
|
|
|
|
|
|
|
|
|
|
|
Ich kenn mich weder mit Javascript noch mit entsporechenden Frameworks aus. Bisher hatte ich auch noch nicht das Bedürfnis, Rich Internet Applications zu schreiben. Deshalb hab ich einfach mal ganz grundlegende Fragen.
Was grenzt Gara eigentlich von etablierten Frameworks wie MooTools oder Prototype ab? Ich hab letztens sogar soein Projekt gesehen das Cocoon komplett im JS implementiert hat.
Auf den ersten Blick fällt mir nur auf, dass Gara nicht unbedingt Funktionen mitbringt um Ajax-Features zu realisieren.
Also das mit den Tabellen z.B. ist ja schön und gut, aber mehr als die Zelle zu markieren kann man in der Demo nicht. Deswegen frage ich mich als Laie natürlich, warum ich meine Daten in einer von JS verwalteten Liste unterbringen sollte, als schlich in HTML. Sinn würde es für mich machen, wenn man die Tabelle per Drag&Drop umsortieren könnte, aber das ist ja (bisher?) nicht der Fall. Nicht geplant oder noch nicht implementiert?
Die Popups, Reiter und Inputs finde ich ziemlich nett. Aber braucht man dafür ein Framework?
Also ums zusammenzufassen: Mir fehlt der praktische Bezug. Wofür braucht man sowas in der Webgestaltung? Was ist hierbei besonders bei Gara (außer dass es dem MVC unterliegt und irgendwas mit eclipse zu tun hat)?
|
|
|
|
|
|
|
|
|
|
|
|
Habe mir gerade nocheinmal MooTools angesehen. Das Projekt hat sich ganzschön gemausert, tolle Sachen damit machbar.
|
|
|
|
|
|
|
|
|
|
|
Berechtigte Frage:
Was die etablierten Frameworks so tun: Mootools, prototype, jquery, dojo, etc. Ich muss gestehen, ich habe noch keines von denen praktisch benutzt, aber deren Hauptaufgabe sehe ich darin, DOM manipulationen vorzunehmen, Effekte anzuwenden und die Arbeit mit dem Standard-Javascript zu vereinfachen - korrigiert mich, wenn ich da falsch liege. Obwohl viele/jedes derer mit einem UI-Package daher kommt.
Meiner Meinung nach ist das (bis auf die Effekte) mit JavaScript-Boardmitteln zu erledigen, deswegen setzt gara oben drauf.
Bei gara ist es so, dass es diese Controls gibt, im Widget package. Diese sind eigentlich mehr Mittel zum Zweck. Eigentlich interessant sind die Viewer.
So schreibt man sich einmal einen Controller für seine Model-Architektur. Darüber lässt sich mit wenigen Zeilen die Response des XHR-Requests in seiner View updaten:
| |
| Code: |
var response = request.responseText;
view.setModel(reponse.data);
view.refresh(); |
|
Die eigentlichen Objekte werden also an die Items gebunden, die in den Controls gezeigt werden.
Darüber hinaus ist jedes Widget um Listener ergänzbar. Somit können mouse und keyboard Events am Widget abgefangen und ausgewertet werden. Ein Beispiel wäre: An einer Liste einen mousedown-listener anzuhängen. Dieser bekommt Notiz, wenn in der Liste ein mousedown event getriggert wird. Darüber kann er von der Liste das aktuell selektierte Item abfragen. Das ist verbunden mit dem assoziiertem Objekt, mit dem man arbeiten möchte.
Das ist mit der Interessanteste Punkt an gara. Eclipse JFace hat mich dahingehend inspiriert, das fürs web umzubauen. Dadurch erhält man auf der Clientseite eine ordentliche Applikations-Struktur und schreibt sauberen und hübschen Code.
Hier ist das nötige AJAX-Snippet:
| |
| Code: |
function XHR() {
var xmlhttp;
try {
xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
} catch (e) {
try {
xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
} catch (e) {
xmlhttp = false;
}
}
if (!xmlhttp && typeof XMLHttpRequest != "undefined") {
try {
xmlhttp = new XMLHttpRequest();
} catch (e) {
xmlhttp = false;
}
}
return xmlhttp;
} |
|
Ich hab hier nochmal eine älteres proof-of-concept ausgegraben. Ich hab es eben schnell auf die neue gara version geupdated, es können allerdings noch Funktionseinbuße irgendwo sein. Ich glaube im IE6 geht die Demo auch nicht, weil er den CSS-Selektor > nicht versteht, zumindest sieht sie nicht hübsch dann aus.
Hier ist sie: http://gara.creative2.net/showcase/keekoadmin/pages
| | | Sinn würde es für mich machen, wenn man die Tabelle per Drag&Drop umsortieren könnte, aber das ist ja (bisher?) nicht der Fall. Nicht geplant oder noch nicht implementiert? | |
Im Moment lassen sich die Columns per D&D einfach umsetzen. Ebenso wäre es möglich einzelne Columns an- und abzuschalten, aber das wäre dann Logik der Applikation, in der die Table eingesetzt würde.
Eigtl. wollte ich mit der 1.0 einen Feature Freeze machen, aber ich glaube, dass ich noch die Sorter und Filter für die Viewer hinzufüge, womit sortieren und filtern möglich wäre, auch mit eigenen Sortier- und Filtermechanismen.
- uni
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von unitrialer am 06.09.2008 15:46]
|
|
|
|
|
|
|
|
|
|
Ah okay, leuchtet mir ein. Danke für die Ausführungen.
|
|
|
|
|
|
|
|
|
|
|
Ich muss sagen dass sich mir der Sinn deines Toolkits nicht wirklich erschließt.
Persönlich habe ich bisher immer mit großer Zufriedenheit Mootools benutzt, da dieses Framework praktisch alles kann was man benötigt.
Damit meine ich Effekte ohne Ende, DOM Manipulationen, XHR, JSON, CSS Selektoren, Events usw.
Das ganze geht dann komprimiert in ca 80kb rein, bei dir sinds schon 163.
Das scheint mir zumindest für die Demos die du anbietes viel zu viel zu sein.
Konzentriert sich dein Kit auf eine komplett andere Richtung?
|
|
|
|
|
|
|
|
|
|
|
Ja, wie ich oben beschrieben habe.
Wie gesagt, es ist ein Webclone von Eclipse SWT/JFace. Und grundlegend wird das MVC Prinzip mit JavaScript realisiert.
Die eigentliche größe müsste ungefähr bei 140kb lieben, die eingebunden libraries die ich nutze. Dennoch die Größe liegt in der Fähigkeit der Widgets und der Viewer und dabei ists noch nichtmal vollständig. Ein gelungenes Beispiel hab ich hier mal beigefügt, es ist die Gruppenverwaltung in meinem neuen CMS:
Keeko Group Management
Außerdem, um die Viewer mal zu demonstrieren, hier der Filemanager. Das Model mit den Inhalten eines Verzeichnisses wird in 3 Views dargestellt:
Keeko Filemanager List View
Keeko Filemanager Table View
Keeko Filemanager Tile View
Ob das so ohne weiteres mit einem der herrkömlichen Toolkits geht? Ich denke nicht ohne weiteres. Die Codezeilen dafür sehen etwa so aus:
| |
| Code: |
var listView = new gara.jswt.ListViewer(...);
var tableView = new gara.jswt.TreeViewer(...);
var tileView = new gara.jswt.ListViewer(...);
var controller = new MyController();
listView.setLabelProvider(controller);
listView.setContentProvider(controller);
listView.setModel(myModel);
// für die anderen 2 viewer die gleichen zeilen
|
|
zum updaten aller 3 views, wenn der XHR-Request zurück kommt (wie oben):
| |
| Code: |
var response = request.responseText;
listView.setModel(reponse.data);
tableView.setModel(reponse.data);
tileView.setModel(reponse.data); |
|
Darauf setzt gara. Gibt eben der Anwendung einen klaren Code, der super wartbar ist.
Fragt ruhig Probiert es aus. Committed Bugs. Committed Code 
|
|
|
|
|
|
|
|
|
|
|
Du hörst Musik mit komischen Liedtiteln.
/e: Im übrigen find ichs auf den ersten Blick doch recht schnieke.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SirSiggi am 17.09.2008 23:10]
|
|
|
|
|
|
|
|
|
| | Zitat von unitrialer
Ja, wie ich oben beschrieben habe.
Wie gesagt, es ist ein Webclone von Eclipse SWT/JFace. Und grundlegend wird das MVC Prinzip mit JavaScript realisiert.
Die eigentliche größe müsste ungefähr bei 140kb lieben, die eingebunden libraries die ich nutze. Dennoch die Größe liegt in der Fähigkeit der Widgets und der Viewer und dabei ists noch nichtmal vollständig. Ein gelungenes Beispiel hab ich hier mal beigefügt, es ist die Gruppenverwaltung in meinem neuen CMS:
Keeko Group Management
Außerdem, um die Viewer mal zu demonstrieren, hier der Filemanager. Das Model mit den Inhalten eines Verzeichnisses wird in 3 Views dargestellt:
Keeko Filemanager List View
Keeko Filemanager Table View
Keeko Filemanager Tile View
Ob das so ohne weiteres mit einem der herrkömlichen Toolkits geht? Ich denke nicht ohne weiteres. Die Codezeilen dafür sehen etwa so aus:
| |
| Code: |
var listView = new gara.jswt.ListViewer(...);
var tableView = new gara.jswt.TreeViewer(...);
var tileView = new gara.jswt.ListViewer(...);
var controller = new MyController();
listView.setLabelProvider(controller);
listView.setContentProvider(controller);
listView.setModel(myModel);
// für die anderen 2 viewer die gleichen zeilen
|
|
zum updaten aller 3 views, wenn der XHR-Request zurück kommt (wie oben):
| |
| Code: |
var response = request.responseText;
listView.setModel(reponse.data);
tableView.setModel(reponse.data);
tileView.setModel(reponse.data); |
|
Darauf setzt gara. Gibt eben der Anwendung einen klaren Code, der super wartbar ist.
Fragt ruhig Probiert es aus. Committed Bugs. Committed Code
| |
Dein Kit scheint sich also an der Lösung solcher Probleme wie zB CMS zu orientieren, das ist mir jetzt klar.
Mit anderen Kits ginge das wohl auch, allerdings müsste man dann halt noch eine eigene Klasse einfügen, aber so viel Aufwand wäre das auch nicht.
Versteh mich nicht falsch, ich find das Kit schon toll, aber ich denke dasselbe ließe sich auch nur mithilfe einer 20kb Mootools Klasse realisieren. Mít Effekten! 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Teufel
Dein Kit scheint sich also an der Lösung solcher Probleme wie zB CMS zu orientieren, das ist mir jetzt klar.
| |
Nein, man kann es allgemein für jede RIA benutzen. Der hier dargstellte Fall ist nur ein CMS.
| | Zitat von Teufel
Mit anderen Kits ginge das wohl auch, allerdings müsste man dann halt noch eine eigene Klasse einfügen, aber so viel Aufwand wäre das auch nicht.
Versteh mich nicht falsch, ich find das Kit schon toll, aber ich denke dasselbe ließe sich auch nur mithilfe einer 20kb Mootools Klasse realisieren. Mít Effekten!
| |
Nunja, du hast halt immer eine Verzahnung, zwischen Model und Item im Widget, weil es das gleiche ist. Mit dem Prinzip oben, habe ich eine Klare Trennung zwischen Präsentation, Logik und Darstellung. Dein Code sieht danach natürlich auch so aus - viel Spaß beim warten. Effekte, im übrigen, halten nur vom Arbeiten ab
|
|
|
|
|
|
|
|
|
|
|
Ich persönlich ein gutes Framework/Toolkit sollte die Arbeit mit JS vereinfachen.
zB ein CSS Selektor mit einer foreach Methode implementiert kann sehr nützlich sein.
Dann noch Sachen wie angenehme Ajax- und JSON-Verwaltung, DOM Manipulationen, Cookies usw.
Ich habe allerdings noch nicht irgendeine Art CMS oder ähnliches programmiert, also war ich noch nicht auf die Art Javascript angewiesen die dein Kit anbietet.
|
|
|
|
|
|
|
|
| Thema: gara - JavaScript Toolkit |
|
