First step: get rid of the messy workaround for the problem that
notifications got lost once the whole body is re-rendered. This
should be solved either on server side or by detaching and re-
attaching existing notifications in such scenario.
Especially on browsers with slow JS like IE8 iterating again and again
over all rows used to harm response rendering. Immagine a dasboard with
a total of a few hundred rows refreshing every 10 seconds while taking
3 secs to render one dashlet... it's far better right now.
refs #6417
Ongoing error handling cleanup silently dropped notifications for
requests with "invalid" target (e.g. commands not redirecting after
submission - they should not exist, but they do).
This is redundant code, but that's ok for now - response handling will
be restructured.
fixes#6327
refs #6280
This is just a first step, trying to catch a few gotchas:
* it doesn't send notifications to the browser when issueing a redirect
as redirects can currently not be catched in jQuery response handlers
* it tries to find a better notification handling place in the response
handler (JS) - still imperfect
* it explicitely stores sessions once modified by notifications. Still
need to crosscheck whether this is really needed and how we can get
rid of this.
refs #6280
I missused the "impact" CSS class for this as it perfectly fit's this
use case. A container loading slow IS an impact. Added CSS transitions,
this way it feels better on modern browsers. The longer it takes to
load a page the darker will get it's background.
Add the abillity to select multiple rows, with a multi-selection using the
CTRL-key or a range-selection using the shift-key. Also fix several issues in
the Multi-Controller of the Backend.
refs #5765
* introduce 'rendered' event for modules
* use this.module.on() instead of registerEventHandlers()
* no CSS filter creates event handlers on module containers
Thomas Gelf
Gunnar Beutner
Matthias Jentsch
Johannes Meyer
Alexander Klimov