Die Extension registriert folgende Hooks:

• cssCompressHandler – zum Komprimieren der CSS Dateien
• jsCompressHandler – zum Komprimieren der JavaScript Dateien
• concatenateHandler – zum Bündeln der Dateien
• clearCachePostProc – zum Löschen der gecachten Dateien im typo3temp Verzeichnis

CSS Komrpimierung

Hierbei wird das Tool CSSTidy verwendet.  Die Konfiguration lässt sich über den Extension Manager in Typo3 einstellen.

Die CSS Datei wird in einem neuen Verzeichnis abgelegt. Die Extension versucht dabei die relativen Pfade in der CSS Datei auf Bilder um zuschreiben. Hier ist eventuell noch Anpassungbedarf.

Damit die CSS Datei komprimiert wird muss folgender Typo Script Code ergänzt werden:

page {
includeCSS {
 screenStyle = ..../base.css
 screenStyle {
   media = screen
   import = 0
   compress=1
 }

JavaScript Komprimierung

Für das JavaScript wird die JSMin Klasse aus dem Typo3 Core verwendet. Es wird nicht die t3lib::minify… verwendet, da diese nicht so effektiv ist.

In TypoScript kann die Komprimierung einzeln ein und ausgeschaltet werden:

page{
 includeJS {
 file1 = ....common.js
 file1.compress=1
...

Bündelung

Die Bündelung der Javascripte und CSS Dateien kann über TypoScript aktiviert werden.  Dafür gibt es diese Einstellung:

config.concatenateJsAndCss = 1

Hierbei ist nicht möglich CSS und JavaScript unterschiedlich zu behandeln. Deshalb gibt es in der Extension die Möglichkeit über den Extension Manager die Bündelung beispielsweise für CSS auszuschalten.

Wenn bestimmte Dateien auf jeder Seite benötigt werden, dann macht es Sinn diese als Libs einzubinden. Dafür gibt es im TypoScript die Option includeJSlibs.

page.includeJSlibs{
  jquery = ...jquery-1.3.2.min.js
  ...
}

Dann werden die in eine separate Datei geschrieben und können vom Browser separat gecacht werden.

Caching

Die komprimierten und gebündelten Dateien werden in dem typo3Temp Verzeichnis abgelegt. Die Cache Datei werden nicht erneuert sondern müssen gelöscht werden um neu erzeugt zu werden. Das Löschen passiert automatisch wenn im Typo3 Backend der Cache gelöscht wird.

Javascript und CSS aus den Plugins hinzufügen

Wenn man früher in einem Plugin JavaScript oder CSS Daten hinzufügen wollte ohne TypoScript hat man das über $GLOBALS['TSFE']->additionalHeaderData machen. Da diese Daten nicht als JS oder CSS deklariert sind nutzen sie in diesen Kontext nichts mehr.  Man kann jetzt mittels $GLOBALS['TSFE']->getPageRenderer() auf den PageRenderer zugreifen und diesen die JS und CSS Dateien bekannt machen. Wenn man mit dem PageRenderer arbeitet kann man auch die Vorteile der Komprimierung und Bündelung nutzen. Es lohnt sich deshalb die Klasse t3lib_PageRenderer genauer anzuschauen.

Mit dem List Filter lassen sich diese Checkboxen darstellen. Die Werte darin sind aber statisch hinterlegt. Man kann auch einen Store im Filter hinterlegen und dann die Werte serverseitig laden. In meinen Fall sollte ich aber die Werte aus den Daten des Grid automatisch ermitteln.

Dazu habe ich erst mal den Ext.data.Store um einen Methode erweitert, die mir die eindeutigen Wert einer Spalte zurückgibt:

Ext.override(Ext.data.Store, {
    getUniqueData:function (index){
        this.unique_data = new Array();
        this.each(function(record){
            var value = record.get(index);
            if(this.unique_data.indexOf(value)==-1){
                this.unique_data.push(value);
            }

        },this);
        return this.unique_data;
    }
});

Dann habe ich mir einen neuen Filter erzeugt, abgeleitet von der Klasse: Ext.ux.grid.filter.ListFilter die nur zwei Optionen benötigt:

1. uniqueStore: eine Referenz auf den Store des Grid
2. dataIndex: der Spalten Index

Der Filter hängt sich an den load Event des Store vom Grid und erzeugt danach seine eigenen Optionen:

Ext.ux.grid.filter.UniqueListFilter  = Ext.extend(Ext.ux.grid.filter.ListFilter, {
    init : function(){
        this.uniqueStore.addListener('load',function(){
            this.options = [];
            var values = this.uniqueStore.getUniqueData(this.dataIndex);
            Ext.each(values,function(value){
                this.options.push([value, value]);
            },this);
            Ext.ux.grid.filter.UniqueListFilter.superclass.init.call(this);
        },
        this
        );
    }
});

Diesen Filter kann einfach in meinen GridFilters instanzieren:

var filters = new Ext.ux.grid.GridFilters(
            {
                local:true,
                filters:[
                    {type: 'string',  dataIndex: 'Account'},
                    {type: 'numeric', dataIndex: 'BasePrice'},
                    new Ext.ux.grid.filter.UniqueListFilter({
                        uniqueStore:ds,
                        dataIndex: 'BaseCurrency'

                    }),
                ]
            }
        );

Im Grid werden die filter über die plugin Schnittstelle eingebunden:

plugins: [filters,...],

In meinen Projekt kam es öfters vor das die Werte nicht eins zu eins aus der XML Datei übernommen wurden, sondern mittels einer individuellen Render Funktion für die Ausgabe abgepasst wurde.

cm: new Ext.grid.ColumnModel([
            {
                header: "XY",
                width:80,
                sortable:true,
                dataIndex:'abc',
                renderer :function(...
            },

Das funktioniert zwar einwandfrei, aber da das nur in der Ausgabe geschieht, kann ich nicht nach dieser Spalte sortieren, oder in dieser per Filter suchen.

Auch an anderen Stellen habe ich deshalb nach einer Möglichkeit gesucht, den Wert im Reader manuell anzupassen.Versteckt in der der Dokumentation der Klasse Ext.data.Record habe ich die Möglichkeit einer convert Funktion gefunden.

Neben dem Mapping kann man über die Eigenschaft convert eine Callback Funktion angeben mit der man den Wert individuell bearbeiten kann.

reader: new Ext.data.XmlReader({
                    record: 'item'
                }, [{
                    name: 'nominal',
                    mapping: 'price@nominal',
                    convert:function(v,r){
                        var value = "K";
                        if(parseFloat(v)<0){
                            value =  "V";
                        }

                        value += '-' + Ext.DomQuery.selectValue('base-currency', r);
                        value += '/' +Ext.DomQuery.selectValue('quote-currency', r);
                        return value;
                    }
                }

Somit erzeuge ich einen individuellen Dataindex nach dem ich auch sortieren und filtern kann.

Bundles

Besonders praktisch ist die Möglichkeit, viele Dateien zu einen Bundle zusammenzufügen. Somit kann man auch die Anzahl der Request reduzieren, aber in der Entwicklung mit vielen einzelnen JS und CSS Dateien arbeiten.  Optimalerweise, sollte man für jede Javascript Klasse eine eigene Datei verwenden.

Installation mit Maven 2

Die Installation in einen Maven Projekt ist genial einfach. Man fügt in die Pom Datei nur folgende Zeile ein:

<dependency>
      <groupId>net.jawr</groupId>
      <artifactId>jawr</artifactId>
      <version>[2,]</version>
</dependency>

Ein Repository muss man auch noch einfügen:

<repository>
          <id>maven2-repository.dev.java.net</id>
          <name>Java.net Repository for Maven</name>
          <url>http://download.java.net/maven/2/</url>
          <layout>default</layout>
</repository>

Log4J

Jawr benötigt zusätzlich Log4J. Deshalb muss noch folgende Abhängigkeit eingefügt werden:

<dependency>
        <groupId>log4j</groupId>
        <artifactId>log4j</artifactId>
        <version>1.2.15</version>
        <type>jar</type>
        <scope>compile</scope>
        <exclusions>
            <exclusion>
                <groupId>com.sun.jmx</groupId>
                <artifactId>jmxri</artifactId>
            </exclusion>
            <exclusion>
                <groupId>com.sun.jdmk</groupId>
                <artifactId>jmxtools</artifactId>
            </exclusion>
            <exclusion>
                <groupId>javax.jms</groupId>
                <artifactId>jms</artifactId>
            </exclusion>
        </exclusions>
 </dependency>

Hierbei ist es wichtig dass die JMX Abhängigkeit ausgeklammert wird, da Maven sonst eventuell nicht startet.

In die web.xml müssen nun noch die Servlets und das Mapping eingetragen werden:

<servlet>
        <servlet-name>JavascriptServlet</servlet-name>
        <servlet-class>net.jawr.web.servlet.JawrServlet</servlet-class>
        <init-param>
            <param-name>configLocation</param-name>
            <param-value>jawr.properties</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet>
        <servlet-name>CSSServlet</servlet-name>
        <servlet-class>net.jawr.web.servlet.JawrServlet</servlet-class>
        <init-param>
                <param-name>configLocation</param-name>
                <param-value>jawr.properties</param-value>
        </init-param>
        <init-param>
                <param-name>type</param-name>
                <param-value>css</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>JavascriptServlet</servlet-name>
        <url-pattern>*.js</url-pattern>
    </servlet-mapping>
    <servlet-mapping>
        <servlet-name>CSSServlet</servlet-name>
        <url-pattern>*.css</url-pattern>
    </servlet-mapping>

Konfiguration

Die Konfiguration geschieht in der jawr.properties

jawr.debug.on=false
jawr.gzip.on=true
jawr.gzip.ie6.on=false
jawr.charset.name=UTF-8

Jawr erkennt automatisch ob der Browser gzip unterstützt. Wenn die Einstellung jawr.debug.on auf true steht, werden Dateien nicht komprimiert und die Bundles werden einzeln geladen. Das ist in der Entwicklung sehr wichtig.

jawr.js.bundle.basedir=/js
jawr.js.bundle.names=lib,core,model

jawr.js.bundle.lib.id=/bundles/lib.js
jawr.js.bundle.lib.mappings=/js/lib/**

jawr.js.bundle.core.id=/bundles/core.js
jawr.js.bundle.core.mappings=/js/helper/**,/js/.../version.js,/js/.../all/**

jawr.js.bundle.model.id=/bundles/model.js
jawr.js.bundle.model.mappings=/js/kosmos/cockpit/**,/js/.../../DragAndDrop.js,/js/.../reportone/**

Hier definiere ich 3 verschiedene Bundles. Die Bundles können aus ganzen Ordnern oder einzeln Dateien bestehen. Doppelte Dateien überspringt Jawr automatisch.

jawr.css.bundle.basedir=/css
jawr.css.bundle.names=style
jawr.css.bundle.style.id=/style.css
jawr.css.bundle.style.mappings=/css/**
jawr.csslinks.flavor = xhtml

Hier wird ein CSS Bundle definiert. Wichtig ist die Einstellung jawr.csslinks.flavor = xhtml , da der Link Tag sonst nicht geschlossen wird.

In der JSP muss nur noch die Taglib angegeben werden.

<%@ taglib uri="http://jawr.net/tags" prefix="jwr" %>

Und dieTags für die Bundles eingefügt werden.

<jwr:style src="/style.css" media="all" />
<jwr:script src="/bundles/lib.js"/>
...

Den Unterschied merkt man bei umfangreichen Javascript Anwenungen deutlich.

Wenn ich also das Lightbox Modul verwenden möchte, füge ich nur folgenden Code in der Action Methode ein:

$this->view->dojo()->enable();
$this->view->dojo()->requireModule('dojox.image.Lightbox');
$this->view->headLink()->appendStylesheet('/js/dojox/image/resources/Lightbox.css');

Zusätzlich hat das Dojo Framework die praktische Eigenschaft, dass es sich alle zu dem Modul notwenigen Module selber nach per Ajax lädt.

Mit der Methode addOnLoad() kann ich eine Funktion definieren, die beim Laden der Seite aufgerufen wird. Dadurch kann man an verschiedenen Stellen eine Funktion zum Onload Ereignis hinzufügen ohne dass diese sich überschreiben.

$this->view->dojo()->addOnLoad('initLightbox');

In einer seperaten JavaScript Datei habe ich das Initialisieren der Lightbox definiert.

var initLightbox = function(){
	dojo.query(".thumbs li a").forEach(function(node, index, arr){
		var href = dojo.query('img',node)[0].src.replace('/thumbs/','/pics/');
		var lb = new dojox.image.Lightbox({title:dojo.query('.tipp',node)[0].innerHTML, group:"group2", href:href ,style:'padding:40px;'});
		lb.startup();
		dojo.connect(node,'onclick',function(e){
			e.preventDefault();
			lb.show();
		});
	});
}

Dieser Code erzeugt aus einer einfachen Liste mit Links auf Bilder einer schönen Light Box mit Blätter Funktion.

<ul class="thumbs">
	<li>
		<a id="68" href="/galery/picture/id/68"><img width="100" height="67" src="/images/galeries/1/thumbs/001.jpg" alt="56 x 42 cm" /></a>
	</li>
	....

In meinen letzten ExtJS Projekt war die Anwendung etwas umfangreicher so das verschiedene Viewports verwendet wurden um die verschiedenen Bereiche abzutrennen. Dazu wurde immer die komplette Seite neu geladen. Bei der Masse an JavaScript Dateien hat sich dieser Switch mit Reload als unangenehm erwiesen. Deshalb habe ich nach einer Möglichkeit gesucht den Viewport zu Laufzeit auszutauschen.

Der logische Weg mittels “destroy” den alten Viewport zu zerstören und einfach einen neuen zu erzeugen, funktionierte leider nicht, da der Viewport zu stark in den DOM Baum verankert ist.

Nach einigem Suchen wurde mir klar das die Regionen einens Viewports nicht mehr änderbar sind sobald sie erzeugt wurden. Man kann nur dessen Inhalt (items) entfernen und dann neue Elemente hinzufügen.

Um die Elemente einer Region zu entfernen habe ich folgende Funktion an mein Viewport ergänzt:

    /**
     * Remove all Items from a Region
     * @param    string    region
     */
    removeAllItems:function(region){
        this._tempcmp = Ext.getCmp(region);
        var mixedCollection = this._tempcmp.items;
        mixedCollection.each(function(item,index,length){
            this._tempcmp.remove(item);
        },this);
    },

Nach dem ich die Region geleert habe hole ich mir die Region mit Ext.getCmp() und füge mit der add Methode die neuen Items hinzu.
Ganz am Ende muss ich noch die doLayout() Methode des Viewports aufrufen damit die neuen Elemente neu gerendert werden.

Wenn man die Code richtig aufbaut kommt man bei dieser Methode auch ohne doppelten Code aus.

Die Einarbeitung hat am Anfang etwas länger gedauert als bei anderen Javascript Frameworks aber als ich dann mal das Prinzip hinter der Architektur erkannt hatte, dann ging die Entwicklung extrem schnell.

Ein wenig erinnerte mich das an die ASP.NET Controlls. Bei diesen muss man auch vorher wissen welches Controll für welche Aufgaben geeignet ist und wo die Grenzen sind. Ganz so extrem ist die Auswahl bei ExtJS zum Glück nicht.

Sauberer Code

Der Code von ExtJS ist sehr sauber und einheitlich. Deshalb ist es sehr einfach sich in neue Grids und co einzudenken wenn man das Prinzip einmal verstanden hat.

Dokumentation

Die Dokumention als AIR Applikation ist praktisch und habe ich extrem viel genutzt. Es handelt sich dabei aber um eine reine Code Dokumentation und mit dieser kann man schlecht das Zusammenspiel der Komponenten darstellen. Dafür war für mich ein Blick in die Sourcen der Klassen nützlicher als jede Google Suche.

Keine Sackgassen

Oft habe ich beim Einsatz von neuen Frameworks die Erfahrung mit Sackgassen erlebt. Meistens traten diese Probleme auf wenn man verschiedene Komponenten mit einen kombiniert und die dann nicht richtig zusammenarbeiten können. Nicht so bei bei ExtJ, selbst die verrücktestden Aufgaben ließen sich mittels der umfangreichen Plugins lösen.

Ausnahme

Ein Ausnahme war die Verwendung von 2 übereinanderliegenen Dropzonen. Das ließ sich mit einen kleinen unschönen Workarround aber auch lösen. Hier ein Beispiel der Problematik.

Gelöst habe ich das Problem indem ich den startdrag Event von dem beiden Grid abfange und dann während des Dragvorgang die andere Dropzone entferne und beim Beenden des Draggen sie wieder neue erstelle.