- filterSrv expects the parameter to init to be the actual
dashboard object (I'll depend on that later on), so
I had to pass dashboard.current in there, instead of
dashboard
- in the last test, the problem was exactly that again.
- small misunderstanding on my part, fixed the API in the filterSrv back
- renames to match my renames
- init script has to be called or fundefined things happen
After all, we are using the function "template" to apply some
data we pull from the URL or other situations in order to call
a function called template. Hence, filtering doesn't make sense
as a term here.
This rework isn't entirely complete here, I haven't
checked the tests yet and I didn't really test anything
furthermore yet, so bear with this commit breaking things.
Besides that, the goal of this commit was to rework the
filterSrv singleton into a factory, so we move the filterSrv
instance around via the scope. This should be a better solution
than the current situation, because services shouldn't contain
model data - the scope should.
This will eventually straighten out control flow between dashboard,
filters and so on, and allow us to leverage angularJS mechanics more.
The latter has already started, since I could rework a bit of the
existing event infrastructure to watches on times.
The goal is to split up the situation between the dashboard
controller and the current dashboard service. I want to be
able to use the routing in order to select various dashboard
controllers, so I can extend the current scripting
mechanism by implementing new dashboard controllers.
However, to do this in a non-insane way, I need to move as
much functionality as possible into services, so the individual
controllers just need to throw the right set of services
together and add a bit of loading logic.
The new function in metricKeys generalizes what my loadAll
from the previous commit did, it takes a request and a
callback. The request is executed on each graphite installation
and the callback is executed for each result. This makes
implementing loadAll and loadRecursive almost as simple as
it was.
This wasn't all too hard to change, I mostly changed the
single http get to multiple http gets, one for each data
source of type graphite.
It's still not a good idea to call this on the web
frontend, since the whole thing was working for about
20 - 30 minutes when I clicked it, so I'm not
committing my changes to settings.js or the view itself.
The error was that funcDef is just a string parsed from an event
like onMouseDown or something like that. This event is turned
into a function instance, and the function instance has
expected parameters and so forth. However, the number of
parameters was actually checked on the funcDef.
