UPDATE: Noch 13 übrig.

UPDATE: Wie es scheint bekommt nun jeder der schon bei Google Wave registriert ist weitere acht Einladungen. Somit komme ich jetzt auf insgesamt 14 Einladungen, die noch verschickt werden können.

Ich habe vor kurzem eine Google Wave Einladung bekommen. Und nun, da ich die meisten Einladungen an Arbeitskollegen und Freunde verteilt habe und immer noch neun Einladungen übrig sind, dacht ich mir “Machste mal was nobles!”

Da ich persönlich ja gar nicht so auf Gewinnspiele oder Quizfragen etc. stehe mach ich es ganz kurz und schmerzlos: Die ersten neun Leute die diesen Artikel finden und einen Kommentar drunter schreiben bekommen eine Einladung. Die eMail Adresse ist dabei Pflicht, ohne die kann ich euch keine Einladung schicken. Ein Google Konto kann auch nach der Einladung erstellt werden. Aber früher oder später braucht man ein solches.

Google empfiehlt folgende Browser: Internet Explorer 6, Firefox 3.5, Safari 4 und Google Chrome.
Ne scherz, der IE kommt auf sowas natürlich gar nicht klar, weder Version 6 noch 7 noch 8, nur die anderen drei Browser werden von Google empfohlen. Opera (10.01) hat jedoch Probleme mit der Darstellung von Wave. Ich empfehle Iron, die Google-lose Version von Chrome. Warum? Wegen der schnellen JavaScript Engine und der Google-Losigkeit. Das ist kein gelaber, ich selbst hab mir extra Iron installiert, da Firefox zumindest bei der JS Ausführung ein wenig zu langsam ist. Vielleicht hilft auch ein schneller PC, das kann ich mangels letzterem nicht beurteilen.

Aber wenn man zu zweit, jeder mit entsprechender Performance mitttels Wave chattet kann man, und das hab ich erst nicht geglaubt, tatsächlich sehen wie der andere tippt. Vielleicht sollte ich es nochmal erwähnen: Das ist eine Preview Version. Oft bleibt bei alles hängen, Nachrichten kommen erst nach einer gewissen Zeit an, etc.

Nun denn, lasst die Spiele beginnen!

Als ich mir die Dokumentation zu Zend_Acl durchlas war mein erster Gedanke “Mein Gott, ich soll bei jedem Seiten Aufruf die gesamte ACL Struktur laden? Das kann doch nicht euer Ernst sein.”

Natürlich nicht. Erneut Google zur Hilfe gerufen fand ich schnell einen dynamischen ACL Loader im Wiki des Frameworks. Die Lösung! Funktioniert auch super, doch zickte es ein wenig mit Objekte als Resource/Role IDs, selbst dann wenn diese das Zend_Acl_Resource_Interface bzw. das Zend_Acl_Role_Interface implementierten. Also überschrieb ich die entsprechende Methode einfach und fügte so die fehlenden gewünschten Funktionen hinzu.

Blödsinn! Warum? Ganz einfach: Ich hatte sowieso schon eine eigene Version von Zend_Acl::isAllowed() geschrieben (nicht überschrieben, meine Variante gehört zu einem Plugin das für ACL zuständig ist und nicht von Zend_Acl erbt), welche wiederum Zend_Acl::isAllowed() benutzt um festzustellen, ob Peter nun Zugriff hat oder nicht (Ein Name, den ich ständig als Platzhalter benutze, man kann ihn einfach so schnell tippen. Und nein, meine Passwörter enthalten diesen Namen nicht ).

Jedenfalls lade ich nun innerhalb meiner Variante von Zend_Acl::isAllowed() zuerst alle Rollen und Resourcen nach denen gefragt ist (selbstverständlich mit einer Überprüfung ob diese nicht vielleicht schon geladen sind), besorge mir die Berechtigungsdaten aus der Datenbank, verwende entsprechend Zend_Acl::allow() bzw. -::deny() um die Berechtigungen festzulegen und am Schluß Zend_Acl::isAllowed() um nun endlich herauszubekommen wie es um Peters Berechtigungen bestellt ist. Das ACL Objekt sollte statisch deklariert werden um sicherzugehen, dass das Rad nicht ständig neu erfunden wird.

admin.resources.layout.layoutPath = path/to/layout

möglich (wobei “admin” hier der Modulname ist). Doch wie so häufig brachte der Druck auf F5 Ernüchterung, es funktioniert so nicht.

Eine kurze Google Suche ergab, dass man sich einfach ein Front Controller Plugin schreiben kann, das vor dem Dispatchen abhängig vom Modulnamen die entsprechende layout.phtml lädt. Eigentlich genau das was ich wollte, aber es musste doch einen Weg geben ohne zusätzlichen Code dasselbe Ziel zu erreichen.

Also gab ich mich nicht mit diesem Plugin zufrieden und probierte herum, bis mir eine Fehlermeldung die Augen öffnete. Und zwar sucht Zend unter anderem auch im /scripts/views/ Unterverzeichnis eines jeden Moduls nach einer layout.phtml. Also brauchte ich nur die “resources.layout.*” Einstellungen in der Konfiguration entfernen und eine layout.phtml in den eben genannten Verzeichnissen erstellen und – voilà – schon benutzt jedes Modul sein eigenes Layout; krass, oder?

Mir ist gerade eine Idee gekommen, die ich auf digg.com noch nicht gesehen hab.

Wie wäre es, wenn User genauso wie Kommentare digged bzw. buried werden könnten. Jeder Benutzer könnte einen eigenen Grenzwert festlegen, ob die Submissions bei ihm angezeigt wird oder nicht, abhängig davon wie oft der Submitter digged oder buried wurde. Eben wie bei den Kommentaren. Eine Benutzer Kontrolle in einem vollkommen Benutzer-basierendem System.

Das funktioniert zwar nur solange es weniger Poweruser als “normale” User gibt, aber davon ist auszugehen, da diese Submission mehr als 19 tausend diggs bekommen hat.

Wenn ihr das für total bescheuert findet würde ich das gerne wissen

Cheers,

Patrick

Valerio Proietti, Gründer von MooTools, hat gestern im Blog des Frameworks auf den Ajaxian Artikel zur Integration von John Resigs Selector Engine Sizzle in Dojo geantwortet. Genau genommen ist es eine Reaktion auf eine Mail von Resig an einen der MooTools Entwickler. Resig hatte in der Mail zum Ausdruck gebracht, dass er sich freuen würde, wenn MooTools sich der Sizzle-Sache anschließen würde, also wenn man die Hauseigene Selector Engine mit der von John Resig ersetzen würde.

Als ich zurerst von dem Projekt Sizzle hörte, konnte ich es kaum abwarten bis es endlich in MooTools Einzug hält. Doch Valerio hat mit seinem Artikel meine Meinung geändert. Und zwar absolut.

Beispielsweise führt er als Argument an, dass sich so eine Entwicklung eher negativ auf den “Markt” der JavaScript Frameworks auswirken würde. Wenn nun jeder anfangen würde, Teile seines Frameworks auszulagern, würde es irgendwann kaum noch Unterschiede zwischen ihnen geben. So wäre MooTools vielleicht nur noch ein Name, ein jQuery oder ein Dojo das MooTools heißt. Und da hat der Römer gar nicht mal so Unrecht würde ich sagen.

Jetzt aber mal zum technischen Teil.

Valerio hat in dem Artikel außerdem ganz klar zwischen Frameworks und Engines unterschieden. Dabei führt er an, dass man sie nicht mittels SlickSpeed vergleichen könne. Z.B. berücksichtigt MooTools ein geändertes DOM nach dem bereits Queries ausgeführt wurden, Sizzle hingegen legt einen Cache an, der das Ergebnis in SlickSpeed durchschnittlich fünf mal schneller erscheinen läßt.

Der MooTools Gründer wollte aber einen fairen Vergleich zwischen MooTools und Sizzle. Zu diesem Zweck hat er sich eine MooTools Version erstellt, die vom Prinzip her wie Sizzle funktioniert. Mit querySelectorAll und keiner Erweiterung der Ergebnis Nodes. Fair eben. Engine vs. Engine, nicht Framework vs. Engine. Und da hat die MooTools Engine klar die Nase vorn, in allen Browsern.

Lest euch auch den Artikel von Valerio durch, ist ganz interessant.

Spontan fühlte ich mich dazu verpflichtet, diesen Link weiter zu verbreiten; fühlte mich dazu verpflichtet, dem Unrecht im Webdesign entgegenzutreten und dem Ende des Martyriums für Firefox, Opera, Safari und deren standardphilen Freunde einen Schritt näher zu kommen.

UPDATE: Guckt euch den Quellcode an; der beste Chuck Norris Spruch den ich je gesehen hab…

Ihr könnt in der Smarty Developers Group auch euren Senf dazu geben oder in der Smarty Discussion Group einfach mal so über diese tolle Template Engine plaudern.

Beim ausführen des Slickspeed Tests war Peppy dann sagenhafte 2ms schneller als Sizzle. Das war im Firefox 3.

Wow.

Liegt wohl an querySelectorAll().

Aber was mich dann wirklich beeindruckt hat, war der Test im IE7. 1. Sizzle hat teilweise Fehler ausgespuckt, statt Elemente. 2. Peppy war schneller. Der schnellste sogar, mit 101ms. Aber das hat irgendwas mit ‘nem Trick zu tun… Wie auch immer.

Sind jedenfalls sau schnell die Dinger, aber ich werde mich gedulden bis sie in den Frameworks eingebaut sind. Bis dahin lass ich die Finger davon. Vor allem weil mich der Satz “He cheats. He caches elements [...]” ein bischen skeptisch gemacht hat.

Man darf aber auch nicht vergessen, dass John noch nicht mit Sizzle fertig ist. Und ich denke da kann man noch eine Menge erwarten.