There are too many view scripts fiddling with namespaces. There is
still the url helper, not sure why it's not going to be used. I may
roll this back one far day...
This adds quite a bunch of changes. Part of the filter-modifying
complexity has been moved to the filter, the editor widget itself
now makes use of new filter capabilities such as changing operator
or expression type.
Show current title, a well-formated value and a label for each area in a
tooltip and add the ability to customize tooltip labels of InlinePies
refs #6117
We used to do this to blacklist certain parameters to not trigger
heavvy actions twice when navigating through history. We also do
never want to see such parameters in our address bar.
This conflicts with our slightly more complicated new filter URLs,
unless we are able to handle them on client side this is disabled
for now. IMO it should be handled server-side and eventually invol-
ving one more redirect.
Every monitoring controller needs $backend, so why declaring it over
and over again. Created "moduleInit" dummy function in our base action
controller to allow such implementations without polluting init().
It doesn't make much sense to sort history by "hostname" hardcoded to
service-only host columns. Default is now timestamp DESC, internally
this is mapped to raw_timestamp.
This was never thought to be used in frontends. Frontend code ALWAYS
needs to work with unix timestamps, raw timestamps are used internally
(e.g. between View and Query) to achieve better search and sort
performance.
I guess this needs some more investigation, desiredColumns are the
ones the user asked for ([alias => ]column), with column being once
again an alias in the "real" query. Alias resolution used to work
better long time ago, we should reflect on this.
A bunch of things happened here. We distinct FilterChains (or, and,
not) from FilterExpressions (less, greater, equal...). We make use of
our new URL-Parser. We can directly address anonymous filter components
for editing filters. Too much things to explain them in detail, a filter
documentation will follow.
The URL query string parsing done by PHP/ZF doesn't suffice our needs.
This is an implementation preserving filter-related "strange" query
string components while still offering legacy behaviour.
Missing right now: support for [].
Raised connection timeout, helps when talking to DB servers behind
weak links. Please note that I'm not sure whether this really is a
better default.
While it doesn't matter with local sockets, connection overhead will
have an impact with remote database servers. We have to reconnect with
every single request. Persistent connections seem to be no longer as
errorprone as they used to be, but I'd still refuse to switch them on
by default.
What we need is a config setting for connection persistancy and wizards
strongly suggesting to use this when working with remote db servers.
Thomas Gelf
Matthias Jentsch
Michael Friedrich