Monday, February 24, 2014

Handlebars integration with Yeoman’s webapp-generator

I was looking for an instruction on how to add Handlebars to my application based on Yeoman’s webapp-generator. There is an instruction on the old wiki on GitHub, but it’s out-of-date. For this exercise I’ve been using Yeoman 1.1.2 and the 0.47 version of the webapp-generator.

First off, go ahead with step 1 and 2 (but obviously using the latest versions).

There’s no need to load the "grunt-contrib-handlebars" in your Gruntfile.js (step 3), as "require('load-grunt-tasks')(grunt);" is used to load all referenced tasks.

I did some changes to the file structure in step 4, but I guess that’s a matter of taste? One thing to note is the change from “temp” to “.tmp” as this is the temporary directory name being used in other places:

handlebars: {
  compile: {
    files: {
      '.tmp/scripts/compiled-templates.js': [
        '<%= yeoman.app %>/templates/**/*.hbs'
      ]
    },
    options: {
      namespace: 'MyApp.Templates',
      wrapped: true,
      processName: function(filename) {
        // funky name processing here
        return filename
                .replace(/^app/, '')
                .replace(/\.hbs$/, '');
      }
    }
  }
}

The watch task needs some additions to it, as well (step 5). Note the addition on watching .js-files in livereload:

handlebars: {
    files: ['<%= yeoman.app %>/templates/*.hbs'],
    tasks: ['handlebars']
},
livereload: {
    options: {
        livereload: '<%= connect.options.livereload %>'
    },
    files: [
        '<%= yeoman.app %>/{,*/}*.html',
        '.tmp/styles/{,*/}*.css',
        '.tmp/scripts/{,*/}*.js',
        '<%= yeoman.app %>/images/{,*/}*.{gif,jpeg,jpg,png,svg,webp}'
    ]
}

Step 6 handles the configuration of Handlebars tasks being run during build, test and serve:
// Run some tasks in parallel to speed up build process
concurrent: {
    server: [
        'compass:server',
        'copy:styles',
        'handlebars'
    ],
    test: [
        'copy:styles',
        'handlebars'
    ],
    dist: [
        'compass',
        'copy:styles',
        'handlebars',
        'imagemin',
        'svgmin'
    ]
}

Don't forget to get the actual Handlebars package using "bower install handlebars" (step 7).

In step 8, as I changed the file structure - just add
<script src="scripts/compiled-templates.js"></script>
and you're done!

/Mattias

Tuesday, November 5, 2013

Loading Google Maps API asynchronously with RequireJS

With Single Page Web Applications becoming more and more popular, I decided to understand the concepts of various Javascript frameworks a little better. There are literally hundreds of them, but I decided to start with a really nice tutorial written by Alex Young. Cornerstones in this tutorial are BackboneJS, Underscore, Bootstrap and RequireJS.

After been through the tutorial I decided to roll my own project based on the same setup. I wanted to use Google Maps for this, and searched for a way to load the API using RequireJS. Turned out that there are a few different approaches, but the most common seems to be to use the async-plugin created by Miller Medeiros.

Jason Wyatt has another interesting solution which caught my attention. Being new to all this, I really didn't feel like start involving plug-ins from remote repositories. It might be the most natural thing to do, but one step at a time is more my melody.

Jason's solution had some drawbacks mentioned in the comments of his post, such as the way Google loads itself asynchronously and how the return value will be an empty stub before everything is loaded. I guess the point is to put the actual maps implementation in the anonymous callback function, but I'd rather have more separation between the loading mechanism and the implementation. The same actually applies to the async-plugin solution, as far as I can tell.

I updated Jason's implementation to look like this:

  define(['config'], function(config) {

    function AsyncLoad(callback) {
      // create a global callback method for Google to use
      var callbackName = 'googlemaps'+(new Date()).getTime();
      window[callbackName] = callback;

      // load the api asynchronously
      require(['http://maps.googleapis.com/maps/api/js?key=' + config.apiKey + '&sensor=false&callback=' + callbackName], function(){
        // do nothing and wait for callback instead
      });
    }

    return AsyncLoad;
  });
The way to use it is to instantiate it with a callback function as an argument. And the key is to make this function operate on the calling object and not from the window object, i.e. 'this' should point to the calling object. This is where Function.prototype.bind comes in, as it creates a new function where the 'this' keyword is bound to the supplied value.

This is how to use it:

define(['asyncload'], function(AsyncLoad) {
  var App = function() {
    this.loadMaps();
  };

  App.prototype = {
    loadMaps: function() {
      var asyncLoad = new AsyncLoad(this.renderMaps.bind(this));
    },
    renderMaps: function() {
      console.log(this); // the App
      var mapOptions = {
        zoom: 8,
        center: new google.maps.LatLng(-34.397, 150.644),
        mapTypeId: google.maps.MapTypeId.ROADMAP
      }
    }
  };

  return App;
});
The callback function is bound to the App and the renderMaps-function will be called just as if it was done from the the App itself. Now, the good thing that comes out of all this is that the renderMaps-function holds all code related to Google Maps, no matter how it was loaded.

Wednesday, November 28, 2012

Greasemonkey to rescue!

Greasemonkey is an add-on to Firefox that seems to prove to be really useful, so I wanted to give it a spin.

Basically, what it does is to modify webpages on-the-fly as you load them - using JavaScript. Many times I guess people use it to get rid of nasty ads and so forth. There are plenty of other add-ons able to do that - like removing a specific element each time, which doesn't require any coding. What fun is that?

Nonetheless, my first Greasemonkey-script does just that - removes an ad. But for the site in question - www.di.se (all in Swedish) - it isn't as easy as removing an element. The site is divided into 3 rows using a frameset that looks like this:

 
<frameset frameborder="no" framespacing="0" rows="0,210,*">
<frame class="noprint" frameborder="no" framespacing="0" name="historyFrame" noresize="" scrolling="no" src=""></frame>
<frame class="noprint" frameborder="no" framespacing="0" name="headerFrame" noresize="" scrolling="no" src=""></frame>
<frame class="" frameborder="no" framespacing="0" name="contentFrame" noresize="" scrolling="auto" src=""></frame>
</frameset>
As you maybe can tell, removing the second frame (which contains the 210px ad) doesn't cut it, because the third frame (content) will now take it's place.

This is where Greasemonkey comes to rescue! Creating the following script tells Greasemonkey to change to rows-attribute of the frameset to hide the ad frame, allowing the content frame to use all available space:

// ==UserScript==

// @name          Clean up di.se
// @namespace     http://www.technowobble.com
// @description   Removes the top add from www.di.se
// @include     http://www.di.se/
// @grant       none
// ==/UserScript==

var frameset = document.getElementsByTagName('frameset');

if (frameset[0]) {
 frameset[0].rows="0,0,*";
}
It will only be applied to http://www.di.se/ (notice the trailing slash which seems to be required) and I will never have to see the ad again. Sweet. But what more can you do with it? Anything, from removing ads, changing look & feel etc, to do automatic user interface testing or exploiting vulnerabilities, I guess?

Tuesday, August 28, 2012

Fighting Dell!

Ok - so I've been having trouble with my Dell Latitude e5410. What kind of trouble, you ask? Well, I discovered it when listening in on my favorite tunes on Spotify. Intermittent there was a "buzzing" sound for a brief moment, like if my headphones weren't properly attached, or poorly fitted into the jack.

This happened 5-10 times per song and was really annoying me, but I couldn't really figure out what it was. Tried a couple of things, like testing with different headphones, downloading new audio drivers, but it never when away. It even occurred when listening without headphones. And no matter if it was streaming media or music on from my local library.

So I gave up. Sigh! Stopped listening on music while working, that is.

Half a year later, and some hours to kill, I started searching for a solution (again). But how do you Google it? "Dell sound noise"? "Dell e5410 audio buzz"? No luck.

Turned out the magic word was "music", as this issue is most annoying when listening on favorite music, it seems. I finally found this thread, which didn't specifically mention the e5410. It eventually led me to try to upgrade the Intel Storage Controller provided by their Rapid Storage Technology anyway. Simply downloaded the driver from Intel and installed it.

Problem solved. Thanks to a dedicated community. Really - big thank you! Wish Dell was monitoring their own community and supplied hot fixes to issues like these. The driver download section isn't very helpful, even with your computer's identity tag supplied...

Friday, November 25, 2011

Getting filters to play nicely with Spring

After having some struggle with getting filters to integrate well with my Spring context, I decided to write down a small tutorial for it...

To begin with, filters are defined in web.xml and are therefore not automatically part of the Spring application context, which is normally set up using the DispatcherServlet. A good way to abstract away all this is to use the DelegatingFilterProxy, which is a Spring utility class that acts as a filter, but will delegate the doFilter-method to a Spring-managed bean - normally a class extending GenericFilterBean.

As a filter is defined in web.xml and looks for the bean defined in the Spring context in applicationContext.xml, it's not really the set up that I want. Filters are part of a web application and should have access to what's usually defined in webmvc-config.xml, as part of the DispatcherServlet set up. To be able to use, e.g. request scoped beans in applicationContext.xml, you need to defined them as proxied objects in order to have them looked up at a time where the web context is available.

The small application I'll be showing here is set up with an example filter that stores a request header value into a request scoped variable which is available as a Spring bean, and can therefor be autowired in any other Spring bean later on in the execution of the request. This demonstrates a nice way to have a loose coupling between the different components, without having to e.g. pass the information in method variables. It also gives the ability to test the components outside a web context.

To begin with, a normal filter definition using the DelegatingFilterProxy needs to be added to web.xml:

    
    
        Header Filter
        org.springframework.web.filter.DelegatingFilterProxy
        
        
            targetBeanName
            headerFilter
        
    

    
        Header Filter
        /*
    


Make sure the init param "targetBeanName" is set to the name of the Spring bean to delegate to (or rely on the default, where the filter's name is used to look up the bean). Now, let's have a look at the definition of the Spring filter bean and the request scoped bean in applicationContext.xml, incl. the acutal implementation of the filter:

    
    

     
    
        
   


Note how the request scoped bean is defined to be a proxied, using
.

    package com.technowobble.web;

    import java.io.IOException;
    import javax.servlet.FilterChain;
    import javax.servlet.ServletException;
    import javax.servlet.ServletRequest;
    import javax.servlet.ServletResponse;
    import javax.servlet.http.HttpServletRequest;
    import org.springframework.beans.factory.annotation.Autowired;
    import org.springframework.web.filter.GenericFilterBean;

    /**
     * Intercepts all incoming requests and parses out Ninaa headers into a session scoped variable.
     */
    public class HeadersFilter extends GenericFilterBean {
        @Autowired
        private Headers headers;

        @Override
        public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
            if (request instanceof HttpServletRequest) {
                HttpServletRequest httpRequest = (HttpServletRequest) request;
                Headers.Types[] values = Headers.Types.values();
                for (int i = 0; i < values.length; i++) {
                    headers.setHeader(values[i], httpRequest.getHeader(values[i].toString()));
                }
            }

            chain.doFilter(request, response);
        }
    }


For this set up to work and have the filter to acutually be able to look up the real object at runtime, we need to add a RequestListener to web.xml, which will wire up the request context to all beans running outsite of the DispatcherServlet, i.e. our filter.

    
    
      org.springframework.web.context.request.RequestContextListener
    


Ok - so far so good. Let's wire it up together in a controller, which uses an example component that will serve as the component that will use the information gathered from the filter. Note that the component used by the controller is not aware of any request/response objects and doesn't have any parameters in it's methods.

    package com.technowobble.controller;

    import org.springframework.beans.factory.annotation.Autowired;
    import org.springframework.stereotype.Controller;
    import org.springframework.web.bind.annotation.RequestMapping;
    import org.springframework.web.bind.annotation.RequestMethod;
    import org.springframework.web.bind.annotation.ResponseBody;
    import com.technowobble.component.MyComponent;

    @Controller
    @RequestMapping("/myController")
    public class MyController {
        @Autowired
        MyComponent myComponent;
        
        @ResponseBody
        @RequestMapping(method = RequestMethod.GET)
        public String createResponse() {
            return myComponent.getSomethingDependingOnHeaders();
        }
    }


The @ResponseBody is just an easy way to get rid of all view lookups and send the header values straight to the browser...

    package com.technowobble.component;

    import org.springframework.beans.factory.annotation.Autowired;
    import org.springframework.stereotype.Component;

    import com.technowobble.web.Headers;

    @Component
    public class MyComponent {
        @Autowired
        Headers headers;
        
        public String getSomethingDependingOnHeaders() {
            return "You are accepting " + headers.getHeader(Headers.Types.Accept);
        }
    }


Now, check if everything workes as expected by launching the application using "mvn jetty:run" and browse to "http://localhost:8080/technowobble/myController/".

The last thing to report is how to test the MyComponent in a separate JUnit-test... First of all, there's no web context in a JUnit-test, and therefor no notion of a request scope. This is solved by defining a custom scope (implemented by a ThreadLocal implementation) in a separate applicationContext-test.xml which is used in the test.

  
    
      
        
          
        
      
    
  


After this, the actual test is straightforward:

    package com.technowobble.component;

    import static org.junit.Assert.assertEquals;

    import org.junit.Before;
    import org.junit.Test;
    import org.junit.runner.RunWith;
    import org.springframework.beans.factory.annotation.Autowired;
    import org.springframework.test.context.ContextConfiguration;
    import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;

    import com.technowobble.web.Headers;

    @RunWith(SpringJUnit4ClassRunner.class)
    @ContextConfiguration(locations="classpath*:META-INF/spring/applicationContext*.xml")
    public class MyComponentTest {
        @Autowired 
        private Headers headers;
        
        @Autowired
        private MyComponent myComponent;
        
        private static final String ACCEPT = "text/html";

        @Before
        public void setUp() throws Exception {
            headers.setHeader(Headers.Types.Accept, ACCEPT);
        }

        @Test
        public void test() {
            assertEquals(myComponent.getSomethingDependingOnHeaders(), "You are accepting " + ACCEPT);
        }
    }


Note that the headers bean is setup during the setUp()-method and that the myComponent have access to it using normal dependency injection.

That's it. The full source code can be downloaded from here

Thanks for reading!

Tuesday, September 13, 2011

A quick note on something that's been bugging me while using SpringSource STS with the GWT-plugin on my MacBook Pro...

Sometimes, when shutting down the internal devmode server I get an error dialog saying it wasn't able to shut down the process fully (even though it looks shut down in the console window).

When starting it again, it reports port 9997 to be in use already - and consequently fails to start up again. I haven't found a way to find the process within SpringSource STS, even though there are probably several ways of doing it (which I do not know about). Anyhow - I solved it using the "lsof" package (List Open Files).

To find the PID of the process using port 9997, type "lsof -i :9997" in a Terminal window. A simple "kill -9 <pid>" will take care of the rest.

I'm not sure if this happens on other platforms etc, but at least, now you know how to handle it if it hits you!

Thursday, March 3, 2011

Styling individual (and nested) tabs using GWT

I've read several forum entries trying to explain how to style GWT TabLayoutPanels, and there seems to be several ways to do it. The three most common ways are to:

1) Edit the standard.css-file and update the .gwt-TabLayoutPanel, .gwt-TabLayoutPanelTabs, .gwt-TabLayoutPanelTab, .gwt-TabLayoutPanelTabInner and .gwt-TabLayoutPanelContent.
2) Override the styles by putting your own css-file as part of html hostpage.
3) Override the styles in the ui-binder file using the @external keyword.

None of them really fit my needs... I want to be able to style indidividual tabs, including nesting tabs within tabs (with different styling). The methods above changes the globally set stylenames, and applies to all tabs being used in you application.

What I'm looking for is to style the tabs using defined styles in the ui-binder file. This way, the styles will be obfuscated and possible to apply within it's own namespace - hence only applied to individual tabs using that namespace.

Let's see an example of how I have managed to set this up. (I'm sure there are other/smarter/better ways, but looking at the forums - people aren't sharing the secrets...)

First of all, let's create the ui-binder file:

<!DOCTYPE ui:UiBinder SYSTEM "http://dl.google.com/gwt/DTD/xhtml.ent">
<ui:UiBinder xmlns:ui="urn:ui:com.google.gwt.uibinder"
 xmlns:g="urn:import:com.google.gwt.user.client.ui">

 <ui:style type="com.technowobble.client.NestedTabWidget.Style"> 
  
  .my-TabLayoutPanel {
   background-color: red !important; 
  }
  
  .myTabLayoutPanelTab {
   background-color: #DCDCDC !important;
   color: gray !important;
   -webkit-border-top-left-radius: 3px;
   -webkit-border-top-right-radius: 3px;
   -moz-border-radius-topleft: 3px;
   -moz-border-radius-topright: 3px;
   border-top-left-radius: 3px;
   border-top-right-radius: 3px;
   margin-left: 11px !important;   
  }
  
  .myTabLayoutPanelTabSelected {
   background-color: #2E8B57 !important;
   color: black !important;
  }
    
  .myTabLayoutPanelTabsContainer {
   background-color: orange;
   -moz-border-radius-topleft: 10px;
   -webkit-border-top-left-radius: 10px;
   -moz-border-radius-bottomleft: 10px;
   -webkit-border-bottom-left-radius: 10px;
   -moz-border-radius-topright: 10px;
   -webkit-border-top-right-radius: 10px;
   -moz-border-radius-bottomright: 10px;
   -webkit-border-bottom-right-radius: 10px;
  } 
  
  .myTabLayoutPanelContent {
   border-color: #2E8B57 !important;
  }   
  
  .myNestedTabLayoutPanel {
   background-color: lime !important; 
  }
  
  .myNestedTabLayoutPanelTab {
   background-color: black !important;
   color: gray !important;
   -webkit-border-top-left-radius: 3px;
   -webkit-border-top-right-radius: 3px;
   -moz-border-radius-topleft: 3px;
   -moz-border-radius-topright: 3px;
   border-top-left-radius: 3px;
   border-top-right-radius: 3px;
   margin-left: 11px !important;
  }
 
  .myNestedTabLayoutPanelTabSelected {
   background-color: #7B68EE !important;
   color: black !important;
  }
  
  .myNestedTabLayoutPanelContent {
   border-color: #7B68EE !important;
   background-color: fuchsia !important;
   color: white;
  }  
 </ui:style>

 <g:TabLayoutPanel ui:field="tabLayoutPanel" barHeight="2" barUnit="EM" width="400px" height="150px" addStyleNames="{style.my-TabLayoutPanel}">
  <g:tab>
   <g:header>Tab 1</g:header>
   <g:TabLayoutPanel barHeight="2" barUnit="EM">
    <g:tab>
     <g:header>Nested tab 1.1</g:header>
     <g:HTML wordWrap="true">Nested tab 1.1 content</g:HTML>
    </g:tab>
    <g:tab>
     <g:header>Nested tab 1.2</g:header>
     <g:HTML wordWrap="true">Nested tab 1.2 content</g:HTML>
    </g:tab>
   </g:TabLayoutPanel>
  </g:tab>
  <g:tab>
   <g:header>Tab 2</g:header>
   <g:TabLayoutPanel barHeight="2" barUnit="EM">
    <g:tab>
     <g:header>Nested tab 2.1</g:header>
     <g:HTML wordWrap="true">Nested tab 2.1 content</g:HTML>
    </g:tab>
    <g:tab>
     <g:header>Nested tab 2.2</g:header>
     <g:HTML wordWrap="true">Nested tab 2.2 content</g:HTML>
    </g:tab>
    <g:tab>
     <g:header>Nested tab 2.3</g:header>
     <g:HTML wordWrap="true">Nested tab 2.3 content</g:HTML>
    </g:tab>    
   </g:TabLayoutPanel>
  </g:tab>
 </g:TabLayoutPanel>
</ui:UiBinder> 

This file defines a tab panel with two tabs, each of which have a separate tab panel as it's content. The specified style tags pretty much mimics the "standard" style names for a TabLayoutPanel and I've named them thereafter. Remember, they could be named whatever as they will be obfuscated anyway.

The only style that is actually applied directly in the ui-binder file is the .my-TabLayoutPanel, which could just as well have had applied at run-time instead.

Now, let's create the corresponding Java-class, which will style the defined tabs using the above styles:

package com.technowobble.client;

import com.google.gwt.core.client.GWT;
import com.google.gwt.dom.client.Element;
import com.google.gwt.event.logical.shared.SelectionEvent;
import com.google.gwt.event.logical.shared.SelectionHandler;
import com.google.gwt.resources.client.CssResource;
import com.google.gwt.uibinder.client.UiBinder;
import com.google.gwt.uibinder.client.UiField;
import com.google.gwt.uibinder.client.UiHandler;
import com.google.gwt.user.client.ui.Composite;
import com.google.gwt.user.client.ui.TabLayoutPanel;
import com.google.gwt.user.client.ui.Widget;

public class NestedTabWidget extends Composite {

 private static NestedTabWidgetUiBinder uiBinder = GWT
   .create(NestedTabWidgetUiBinder.class);

 interface NestedTabWidgetUiBinder extends UiBinder<Widget, NestedTabWidget> {
 }
 
 interface Style extends CssResource {
  // Tab container (containing the .gwt-TabLayoutPanelTabs styling
  String myTabLayoutPanelTabsContainer();
  // General tab styling
  String myTabLayoutPanelTab();
  // Specific styling for selected tab
  String myTabLayoutPanelTabSelected();
  // Applied to tab content
  String myTabLayoutPanelContent();
  // Applied to entire nested tab panel
  String myNestedTabLayoutPanel();
  // General inner tab styling
  String myNestedTabLayoutPanelTab();
  // Specific styling for selected inner tab
  String myNestedTabLayoutPanelTabSelected();
  // Applied to inner tab content
  String myNestedTabLayoutPanelContent();
 }
 
 @UiField 
 Style style;
 
 @UiField
 TabLayoutPanel tabLayoutPanel;

 public NestedTabWidget() {
  initWidget(uiBinder.createAndBindUi(this));
  
  // style the tab container (gray bar)
  ((Element) tabLayoutPanel.getElement().getChild(1)).addClassName(style.myTabLayoutPanelTabsContainer());
  // style the tabs
  styleTabPanel(tabLayoutPanel, style.myTabLayoutPanelTab(), style.myTabLayoutPanelTabSelected(), style.myTabLayoutPanelContent());
  
  // style all inner tabs (in uibinder)
  for (int i = 0; i < tabLayoutPanel.getWidgetCount(); i++) {
   Widget widget = tabLayoutPanel.getWidget(i);
   
   // add content style no matter what the content is
   widget.addStyleName(style.myTabLayoutPanelContent());
   
   if (widget instanceof TabLayoutPanel) {
    final TabLayoutPanel nestedTabLayoutPanel = (TabLayoutPanel) widget;
    // style inner tabLayoutPanel  
    nestedTabLayoutPanel.addStyleName(style.myNestedTabLayoutPanel());
    styleTabPanel(nestedTabLayoutPanel, style.myNestedTabLayoutPanelTab(), style.myNestedTabLayoutPanelTabSelected(), style.myNestedTabLayoutPanelContent());

    // re-style on selects
    nestedTabLayoutPanel.addSelectionHandler(new SelectionHandler<Integer>() {     
     @Override
     public void onSelection(SelectionEvent<Integer> event) {
      styleTabPanel(nestedTabLayoutPanel, style.myNestedTabLayoutPanelTab(), style.myNestedTabLayoutPanelTabSelected(), style.myNestedTabLayoutPanelContent());      
     }
    });       
   }
  }
 }
 
 @UiHandler("tabLayoutPanel")
 public void onTabSelect(SelectionEvent<Integer> event) {
  styleTabPanel(tabLayoutPanel, style.myTabLayoutPanelTab(), style.myTabLayoutPanelTabSelected(), style.myTabLayoutPanelContent());
 } 
  
 private void styleTabPanel(TabLayoutPanel tabPanel, String style, String styleSeleced, String styleContent) {
  for (int i = 0; i < tabPanel.getWidgetCount(); i++) {
   Widget tab = tabPanel.getTabWidget(i);
   
   // style the actual tab
   tab.getParent().addStyleName(style);
   if (i == tabPanel.getSelectedIndex()) {
    tab.getParent().addStyleName(styleSeleced);
   } else {
    tab.getParent().removeStyleName(styleSeleced);
   }
   
   // style the added content
   Widget content = tabPanel.getWidget(i);
   content.addStyleName(styleContent);
  } 
 }
}

You can see what the different styles are used for in the comments (according to the JavaDoc of the TabLayoutPanel) - the only interesting thing to note is that I've added styling to the div-tag containing the .gwt-TabLayoutPanelTabs div, in order to style the background behind the tabs.

When initializing the widget I style all the tabs once, but as I can't use addStyleDependantName() to style select/unselect I also have to apply these styles on every select/unselect. This is applied to both the outer TabLayoutPanels, as the inner TabLayoutPanels. The reason the addStyleDependantName() can't be used is because the names are obfuscated, and adding a "-select" to it doesn't match the name of the non-obfuscated corresponding selected style in the ui-binder file. There are surely a better way of doing this, and I'd be happy to hear if you have any suggestions here...

I haven't put up any running example of this, but you can download the source code as an Eclipse-project here and try for yourself. I apologize for the color-schema I've used in the example - looks like a 5-year old gone crazy, but it fills the purpose of showing where each style gets applied...

Have fun!