Mittwoch, 17. Oktober 2007

Dieser Blog ist tot. Ich blogge weiter auf dem «Agile Trail».

[Grails eXchange] Session The Grails Plug-in Architecture (Graeme Rocher)

Graeme, Project-Lead des Grails-Projektes, spricht über das Plugin-System von Grails. Es gibt bereits viele Grails-Plugins - und das, obwohl Grails noch nicht 1.0 final ist! Das wird noch richtig abgehen, wenn Grails ausgewachsen ist.

Graeme erzählt von der Historie des Plugin-Systems. Es gab mal eine Zeit, da hatte es ziemlich eklige Stellen in Grails, die dummerweise sehr wichtig waren, wie z.B. das Buildsystem, ein Ant-File mit über 1000 Zeilen. Das war dann irgendwann sehr anfällig für Störungen bei Änderungen und auch schwer zu warten. Was tun? Aufdröseln, auch genannt Modularisierung. So sind dann die Plugins entstanden.

Die Archtiktur von Grails wird umrissen (Plugins, GrailsApplication, ApplicationContext). Ziele der Plugins: DRY und Simplicity. Ein Plugin ist erstmal ein Grails-Project, welches zusätzlich noch einen Descriptor hat, *GrailsPlugin.groovy (das Sternchen steht dann für den Namen des Plugins), welches per grails create-plugin erzeugt werden kann. Mit einem Plugin kann man Methoden, Konstruktoren, etc. dynamisch hinzufügen zu jeder beliebigen Klasse (MOP), Spring-Konfigurationskram, web.xml modifizieren, neue Tag-Libs, Controllertypen, etc. hinzufügen, usw.

Mister Grails erstellt jetzt ein Plugin und zeigt, was man da so alles machen kann. Ich glaub ihm jetzt mal, dass man da sehr viel einstellen kann :-) Man kann ein Plugin laufen lassen wie jedes normale Grails-Projekt auch. Graeme wechselt zu den Folien und zeigt, wie man einem Logging-Plugin relativ einfach beibringen kann (per Meta-Object Programming; schon genial, wie die neue Metaklasse arbeitet - Graeme hat's erfunden!), in jeder Klasse ein log-Attribut zu haben, ohne jedesmal Logger.getLogger(NameOfClass.class) tippen zu müssen.

Das GrailsApplication-Object ist mächtig: man kann überall application.get*Classes() aufrufen, um mit application.getControllerClasses() alle Controllerklassen zu bekommen. Ähnlich einfach kann man eigene Klassen Grails in einem Plugin beibringen.

Artefakte sind Dinge, die eine Konvention erfüllen in Grails, etwa Controllers oder Services o.ä. Artefakte sind alle vom Typ GrailsClass, und haben damit viele nützliche Methoden und Attribute, die bei der Pluginentwicklung helfen.

Plugins zu verteilen ist trivial: grails package-plugin. Dann bekommt man ein zip-File, welches per grails install-plugin path/to/zip in einem anderen Grails-Projekt eingebaut werden kann. Statt dem Pfad kann man auch eine URL angeben: so einfach kann Verteilung übers Netz gehen!

Graeme zeigt kurz, wie man eine TagLib erstellt und per Plugin verteilt. Und jetzt geht Graeme ab: ich komme nicht mehr mit beim Schreiben, so viele Beispiele feuert er gerade ab, ziemlich advanced und alles mit seinen ExpandoMetaClasses. Sieht sehr gut aus!

Jetzt kommen die Reload Events. Danach geht's weiter mit der Kommandozeile, also alles nach dem grails-Kommando. Dafür stellt er nochmal kurz Gant vor. Jedes Kommanodzeilenskript in Grails ist ein Gant-Skript. Ein Skript ist einfach angelegt und kann danach sofort ausgeführt werden. Gewohnt straight forward.

Wie bereits geschrieben, es gibt bereits ein paar Plugins, auf die Graeme jetzt ein wenig eingeht: XFire, Searchable, Remoting, GWT, Acegi/Security, JMS, Wicket/JSF/Tapestry, Dbmigrate, Static Resources, Jasper Reports. Für 1.0 RC 1 sind auch einige Plugins aus dem Core entfernt worden und eigentständige Plugins: Canoo WebTest und Dojo z.B.

"Puh, geschafft", möchte ich fast sagen. Aber nein, es war super, allerdings ist Graeme ein sehr fokussierter Sprecher und geht ab wie ein Maschinengewehr, sowohl was Infos als auch Sprache angeht - schwer für einen Nicht-Native-Speaker. Ich bin begeistert, was Pluginsystem zu leisten vermag und erschüttert, in was ich mich noch einarbeiten muss fürs Buch. Obwohl, über dieses Pluginsystem kann bestimmt noch ein eigenes Buch schreiben.

blog comments powered by Disqus