Somewhat related, but just something I'm opening up for discussion, which is that I wonder if there's a better way we could be handling this pattern on the `PortletBase` level.
We repeat this in a lot of places, but basically, we store an array of event handles, and clean them up in the constructor.

One pattern I've seen in ExtJS is on their equivalent to A.Base, they have a method called `mon` (which I believe is short for "monitor" or "managed on"), but they automatically create the array of event handles, and automatically detach them inside of the destructor. It's basically creates a managed event listener.
I'm not sure if `mon` is the best name for it (I'm open to better ideas, but I do like that it's short and sweet), but I see us doing this pattern all over the place, and I think it would be good to handle it.
(They also have a complementary `mun` method, which unbinds the events and removes the handle).

The method signature they use is `.mon(obj, eventName, fn, context, options)`, which I could see working for us (though the options parameter is specific to them), though I might propose some alternatives for different cases.

So basically, I see a line like this:
```
instance._eventHandles.push(
    defaultLanguageSelector.on('change', instance._changeArticleDefaultLocale, instance)
);
```
to maybe being something like:
```
instance.mon(defaultLanguageSelector, 'change', instance._changeArticleDefaultLocale, instance);
```
or even (following what `A.bind` allows):
```
instance.mon(defaultLanguageSelector, 'change', '_changeArticleDefaultLocale', instance);
// or maybe even dropping the last context object, and defaulting it to the instance?
```
Or for subscribing to events on the instance (in this example, let's say an event named "render"), I could see any of these being nice:
```
instance.mon(instance, 'render', '_renderFn');
instance.mon('render', '_renderFn');
instance.mon('render', instance._renderFn);
instance.mon('render', 'show', someNode);
```

I think there are only two aspects I'm not 100% sure about, handling `after` and `delegate` events.

I suppose we could have `mafter` and `mdelegate` methods as well, but those look a little ugly, and maybe there's a better way to handle them.

This is all just thinking out loud, but let me know what you guys think about cleaning up this pattern, or at least reducing the amount of redundant code.