Ich habe mir gerade mal das dojo.E Projekt näher angesehen und ausprobiert.
dojo.E ist ein Framework, das sich quasi über das eigentliche Dojo (1.1) stülpen lässt. Ziel des Projektes ist es, die Verwendung von Dojo auch in größeren, im Team zu entwickelnden Projekten perfekt zu ermöglichen.
Ohne geziehlte Kenntnisse der Widget-Klassen von Dojo, soll damit auch ein Web-Designer problemlos Dijits in den Seiten (zum Beispiel JSPs oder im Bezug auf TAS die ESPs) einarbeiten können.
Das ganze erinnert dabei ein wenig an die Taglibs in JSPs.
Im #dojo-Channel machte gerade dieser Blog-Eintrag die Runde, den ich niemandem vorenthalten möchte.

see more pwn and owned pictures
Man sollte also besser seinen Firmen-Namen nicht automatisiert übersetzen lassen, wenn man der Zielsprache nicht doch ein wenig mächtig ist...
Zurzeit bin ich dabei, einen Weg zu evaluieren, mit dem es möglich ist, komplexe Anwendungen mit Dojo (und TAS) zu schreiben, ohne sich dabei allzu leicht in Spaghetti-Code zu verlieren.
SitePen, Inc. haben die Dojo Toolbox veröffentlicht. Dabei handelt es sich um eine Adobe AIR-Anwendung (sowas hatte ich bisher noch nicht), die lokal installiert wird und auch offline genutzt werden kann.
Dojo Toolbox
Im Blog gibt es eine ausführliche Beschreibung, deswegen werde ich hier nur kurz meine Eindrücke wiedergeben.
Die Firma IdeaWorks aus USA hat kürzlich einen einfachen, überschaubaren Mini-Tutorial gepostet. Darin wird beschrieben, wie man eigene Dojo-Widgets programmiert. Es ist sicher nicht weltbewegend, aber vielleicht bringt es ja den einen oder anderen weiter:
Idea Works: "Creating Custom Dojo Widgets"
Ich unterziehe TAS gerade einem umgreifenden Refactoring.
Es entfallen dabei einige Extensions, die entweder noch nie oder nicht mehr benötigt werden. Kurz und knapp: Alles was mit Ajax und visueller Aufbereitung zu tun hat.
Warum? Weil das Dojo alles erheblich besser leistet und wir weder die Zeit noch die Ambitionen besitzen, uns um die Oberfläche zu kümmern.
Weil die Frage heute im IRC Channel #dojo aufkam, habe ich mich mal mit folgender Fragestellung auseinander gesetzt.
Eigentlich ganz einfach. Klar, wenn die ComboBox ihre Daten von einem Store erhält, dann muss man dafür sorgen, dass der Store die neuen Optionen bereitstellt.
Was aber, wenn man seine ComboBox (ich meine damit dijit.form.ComboBox) gar nicht an einen Store (wie z.B. ItemFileReadStore) koppelt, sondern die anfänglich verfügbaren Optionen schon im Markup deklariert?
Also zum Beispiel:
Im SitePen Blog beschreibt Dustin Machi, wie man _Templated Widgets (also Widgets, die sich aus der Klasse dijit._Templated ableiten) so schreiben kann, dass deren Template nicht im TemplateString oder gar extern vorgehalten werden müssen.
Sein Ansatz ist sehr interessant, da er es einem erlaubt, verschiedene Ausprägungen eines prinzipiell gleichen Widgets zu erzeugen. Und das einfach an Ort und Stelle, im Quellcode der Seite.
Das Template für das Widget ergibt sich demnach aus dessen Deklarationsblock.
Es gibt nicht sonderlich viel Literatur, die sich mit dem Dojo Toolkit beschäftigt.
Gerade erst heute haben wir in unsere Safari-Bookshelf Dojo: The definitive Guide sowie Dojo: Using the Dojo JavaScript Library to Build AJAX Applications geladen. Zwei brandaktuelle Titel, nur wenige Tage alt.
In seinem Blog Medryx observations geht besagter Medryx ein wenig auf die deferred-Mechanismen von Dojo ein.
Die Beispiele die er da aufführt sind recht eingängig, so dass man recht leicht versteht, um was es eigentlich geht.