The `load` event is not really only fired *after all shared resources are loaded*.
Just Chromium ensures this event is fired only after `ready` and `DOMContentLoaded`.
FF, IE and Safari don't so we need our own post-init event: `icinga-init`
`beforerender` is already too late. Module initialization
done using an event handler is wrong anyway. It's some
kind of bootstrapping after all and should be performed
by parts of the code which is directly responsible for
DOM content handling of modules. (i.e. loader.js)
This change though introduces a side-effect which was
not the case previously: Nested `.container` elements
trigger `rendered` events now. I've introduced this to
ensure we're also lazy loading modules and let them
handle their `rendered` events right after a redirect
which rerendered the layout. (Only `#layout` got a
`rendered` event then prior to this change)
Cleans up how our JS initializes module javascript. Previously the `rendered`
event only got fired upon page load if a module got loaded as well. This is
now decoupled and `rendered` events fire for all containers and the entire
layout upon page load.
Notable changes:
* A `load` event initializes modules and triggers `rendered` on `.container` and `#layout` elements
* Module javascript (module.js) is still lazy loaded but with a `beforerender` event, not `rendered`
* Previously `#layout` received a `rendered` event during bootstrapping, this is not the case anymore
* Initial search value preservation now got its own handler `events.onRenderedMenu()`
* Initial dashlet loading now git its own handler `events.loadDashlets()`
The sidebar state is now maintained per tab/window because users view
different things in different tabs/windows. E.g. users work with a
specific module constantly clicking through the menu while having
other tabs/windows with some important dashboards open.
When the sidebar is closed in one tab/widnow, it should not close
the sidebar in the other tabs/windows.
Johannes Meyer
Florian Strohmaier
Eric Lippmann
Jennifer Mourek