How to change theme in Ext-Gwt (GXT) application

Some time ago Sencha company included new theme in their GXT library. It’s called SLATE and can be viewed in GXT Explorer demo on this site: http://www.sencha.com/examples/explorer.html. I’ve been searching, but I coudn’t find any clear information in web, how to made my gwt app to change theme to new skin instead of standard BLUE or GREY themes. After short investigating I realized, that everything is easy, but only if You keep standard paths in Your app to css/images.

First of all You have to copy to Your’s project directory some directories from GXT example zip file (can be downloaded here: http://www.sencha.com/products/gwt/download.php). Those directories are: css (with BLUE/GREY theme’s csses), images (all gxt standard images) and themes (new SLATE theme). They can be found in resource directory in gxt-x.x.x zip file.

Now, after copying directories to own app in gwt html entry point file it has to be placed following line:   < link rel=”stylesheet” type=”text/css” href=”css/gxt-all.css” /&rt;   That’s all. Nothing more gxt’s csses have to be included (instead of what I’ve found on internet). Why ? Becouse we will switch theme in java code later. In apps entry point java file in onModuleLoad() method we need to insert some code. We want to tell GXT, that we will be using SLATE theme as default, but we would like to change it later. This is made by passing ‘false’ parameter in .setDefaultTheme(..) method. Code for this:   ThemeManager.register(Slate.SLATE); //register non standard theme // Theme.GRAY.set(“file”,”css/gxt-gray.css”); //set custom css’es path for grey theme // Theme.BLUE.set(“file”,”css/gxt-all.css”); //set custom css’es path for standard blue theme // Slate.SLATE.set(“file”,”gxt/themes/slate/css/xtheme-slate.css”); //set custom path for SLATE theme GXT.setDefaultTheme(Slate.SLATE, false); //set default theme to new SLATE skin

That’s not all. If we would like to rearange our paths (i.e. by moving themes/images/css directories in other places) we have to uncoment commented code and set proper paths.

Because we would like to allow user to switch theme by own. We have to add somewhere in our app’s panels ThemeSelector which will do all work. It’s very easy. Just add somewhere this code:

  [ourContainer].add(new ThemeSelector());

You May Also Like

JBoss Envers and Spring transaction managers

I've stumbled upon a bug with my configuration for JBoss Envers today, despite having integration tests all over the application. I have to admit, it casted a dark shadow of doubt about the value of all the tests for a moment. I've been practicing TDD since 2005, and frankly speaking, I should have been smarter than that.

My fault was simple. I've started using Envers the right way, with exploratory tests and a prototype. Then I've deleted the prototype and created some integration tests using in-memory H2 that looked more or less like this example:

@Test
public void savingAndUpdatingPersonShouldCreateTwoHistoricalVersions() {
    //given
    Person person = createAndSavePerson();
    String oldFirstName = person.getFirstName();
    String newFirstName = oldFirstName + "NEW";

    //when
    updatePersonWithNewName(person, newFirstName);

    //then
    verifyTwoHistoricalVersionsWereSaved(oldFirstName, newFirstName);
}

private Person createAndSavePerson() {
    Transaction transaction = session.beginTransaction();
    Person person = PersonFactory.createPerson();
    session.save(person);
    transaction.commit();
    return person;
}    

private void updatePersonWithNewName(Person person, String newName) {
    Transaction transaction = session.beginTransaction();
    person.setFirstName(newName);
    session.update(person);
    transaction.commit();
}

private void verifyTwoHistoricalVersionsWereSaved(String oldFirstName, String newFirstName) {
    List<Object[]> personRevisions = getPersonRevisions();
    assertEquals(2, personRevisions.size());
    assertEquals(oldFirstName, ((Person)personRevisions.get(0)[0]).getFirstName());
    assertEquals(newFirstName, ((Person)personRevisions.get(1)[0]).getFirstName());
}

private List<Object[]> getPersonRevisions() {
    Transaction transaction = session.beginTransaction();
    AuditReader auditReader = AuditReaderFactory.get(session);
    List<Object[]> personRevisions = auditReader.createQuery()
            .forRevisionsOfEntity(Person.class, false, true)
            .getResultList();
    transaction.commit();
    return personRevisions;
}

Because Envers inserts audit data when the transaction is commited (in a new temporary session), I thought I have to create and commit the transaction manually. And that is true to some point.

My fault was that I didn't have an end-to-end integration/acceptance test, that would call to entry point of the application (in this case a service which is called by GWT via RPC), because then I'd notice, that the Spring @Transactional annotation, and calling transaction.commit() are two, very different things.

Spring @Transactional annotation will use a transaction manager configured for the application. Envers on the other hand is used by subscribing a listener to hibernate's SessionFactory like this:

<bean id="sessionFactory" class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean" >        
...
 <property name="eventListeners">
     <map key-type="java.lang.String" value-type="org.hibernate.event.EventListeners">
         <entry key="post-insert" value-ref="auditEventListener"/>
         <entry key="post-update" value-ref="auditEventListener"/>
         <entry key="post-delete" value-ref="auditEventListener"/>
         <entry key="pre-collection-update" value-ref="auditEventListener"/>
         <entry key="pre-collection-remove" value-ref="auditEventListener"/>
         <entry key="post-collection-recreate" value-ref="auditEventListener"/>
     </map>
 </property>
</bean>

<bean id="auditEventListener" class="org.hibernate.envers.event.AuditEventListener" />

Envers creates and collects something called AuditWorkUnits whenever you update/delete/insert audited entities, but audit tables are not populated until something calls AuditProcess.beforeCompletion, which makes sense. If you are using org.hibernate.transaction.JDBCTransaction manually, this is called on commit() when notifying all subscribed javax.transaction.Synchronization objects (and enver's AuditProcess is one of them).

The problem was, that I used a wrong transaction manager.

<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager" >
    <property name="dataSource" ref="dataSource"/>
</bean>

This transaction manager doesn't know anything about hibernate and doesn't use org.hibernate.transaction.JDBCTransaction. While Synchronization is an interface from javax.transaction package, DataSourceTransactionManager doesn't use it (maybe because of simplicity, I didn't dig deep enough in org.springframework.jdbc.datasource), and thus Envers works fine except not pushing the data to the database.

Which is the whole point of using Envers.

Use right tools for the task, they say. The whole problem is solved by using a transaction manager that is well aware of hibernate underneath.

<bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager" >
    <property name="sessionFactory" ref="sessionFactory"/>
</bean>

Lesson learned: always make sure your acceptance tests are testing the right thing. If there is a doubt about the value of your tests, you just don't have enough of them,